Flexus L 开通后的第一步：安全组放行与远程登录配置实操

After activating a Flexus L instance, the first practical job is not installing software. It is making remote access reachable, controlled, and repeatable. This note records the first steps for an instance in CN North-Beijing IV with 2 vCPU, 2 GB of memory, a 40 GB system disk, 2 Mbps of bandwidth, and a one-year term at the ¥36 flash-sale price. The focus is the console flow: confirming the instance, opening the right port, resetting the root password, and then attempting a remote connection in a disciplined way.

1. Confirm the instance before changing anything

In the console, check the region, the instance name, its running state, and its public IP address. Copy the public IP exactly; a wrong IP is one of the most common reasons a first login attempt appears to fail. Also note which security group is attached to the instance, because that group, not a generic default, controls the inbound rules that will matter next.

2. Allow TCP 22 in the security group

Open the security group attached to the instance and add an inbound rule for TCP port 22. This is the SSH port used for remote Linux login. Set the protocol and port precisely, rather than opening a wide range of ports. For the source address, use your own public IP address when that is possible. Opening 22 to all addresses (0.0.0.0/0) may be convenient for a quick test, but it also exposes the instance to continuous automated scanning, so it should not be left as a permanent setting. Keep the rule set minimal: if only SSH is needed at this stage, only SSH should be open.

A useful distinction is that a cloud security group and the firewall inside the operating system are two different layers. A correct security-group rule will not help if the operating-system firewall blocks the same port, and a correct operating-system rule will not help if the security group blocks it. When a connection is refused, check both layers, and check them in order, instead of changing several settings at once.

3. Reset the root password offline, with automatic restart checked

If the initial password is unknown or needs to be replaced, use the console password-reset flow for the instance. Choose a strong, unique password and store it in a password manager; do not reuse a password from another service and do not paste it into a chat or a shared document. In the reset dialog, check the automatic-restart option, because the reset described here is an offline reset and the instance needs to restart for the new password to take effect. Expect a brief interruption, and do not start other configuration changes while the instance is restarting.

Wait until the console again shows the instance as running before trying to connect. Trying to log in during the restart, or immediately after submitting the reset, can produce a misleading failure that looks like a wrong password when the real cause is timing.

4. Attempt the remote connection

From a terminal, connect as root to the public IP address on port 22, for example with ssh root@<public-IP>. On the first connection, the client will show a host-key prompt. Read it rather than accepting it blindly, and confirm that you are connecting to the intended instance. Then enter the newly set password. If access is denied, work through a short checklist before resetting again: is the instance running, is TCP 22 allowed in the attached security group, is the IP address correct, and was the password reset completed with the restart option selected?

5. Pitfalls worth avoiding

First, do not treat a single failed login as proof that the security group is wrong; timing, a mistyped IP, or an incomplete restart can produce the same symptom. Second, do not leave a broad 22 rule in place after testing; narrow the source address once you know your own IP. Third, do not change the password repeatedly in quick succession without waiting for each restart, because that makes it hard to know which password is current. Fourth, keep a record of what was changed: the security-group rule, the source restriction, and the time of the password reset.

Honest status note

This note describes the console flow as set up: security-group release of TCP 22, offline reset of the root password with automatic restart checked, and the remote-connection steps that follow. Password submission and live SSH connectivity verification are still being carried out on the user side, so this article does not claim that a successful SSH login has already been verified. That distinction matters, because a checklist that reports success too early can hide a configuration problem.

Summary checklist: confirm region, state, and public IP; allow inbound TCP 22 in the attached security group with the narrowest workable source; reset the root password offline with automatic restart checked; wait for the instance to return to running; then attempt SSH and troubleshoot one layer at a time.