Managing SSH user login policies for Hong Kong cloud servers

Administrators managing Hong Kong cloud servers often face a core challenge: implementing SSH access control. The first and most direct step is through the SSH service's main configuration file. This file, typically located at `/etc/ssh/sshd_config`, sets the behavior guidelines for the SSH daemon. Creating a backup before modifying any critical configuration is a crucial security practice, providing a safety net for potential rollbacks.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Next, open the configuration file using a text editor such as `vim` or `nano`. The core directives for controlling user access are `AllowUsers` and `DenyUsers`. Their logic is straightforward: `AllowUsers` creates a whitelist, allowing only listed users to log in; `DenyUsers` creates a blacklist, explicitly denying access to specified users. In practice, the whitelist strategy is recommended because it follows the principle of least privilege ("default denial"), offering higher security. For example, to allow only `admin` and `developer` users to log in via SSH, you can add the following line:

AllowUsers admin developer

For further restrictions, you can specify that users can only log in from specific IP addresses. This is common in financial or high-security environments, with a format like `AllowUsers admin@203.0.113.10 developer@198.51.100.0/24`. Similarly, using `DenyUsers` can block known problematic or test accounts. After making changes, you must restart the SSH service for the new configuration to take effect. On distributions using systemd, execute:

sudo systemctl restart sshd

After restarting, be sure to immediately open a new terminal session to test the configuration to avoid being locked out of the server due to misconfiguration.

After configuring the user whitelist, strengthening the basic security settings of the SSH service itself is the next line of defense. Disabling direct login by the root user is a crucial measure. The root account has the highest privileges and is a primary target for attackers. Forcing administrators to log in with a regular account first, and then escalate privileges using `su` or `sudo`, increases the security audit layer and the difficulty of attacks. Locate the `PermitRootLogin` item in the configuration file and set it to `no`:

PermitRootLogin no

Another effective strategy is to change the default port of the SSH service. SSH listens on port 22 by default, and automated attack scripts and network scans continuously probe this port. Changing it to a non-standard port greater than 1024, such as `58222`, can significantly reduce noisy logs and automated attacks. This can be achieved by modifying the `Port` directive:

Port 58222

It is important to note that after changing the port, all SSH clients must explicitly specify the new port when connecting. Simultaneously, it is essential to allow inbound traffic to the new port in the security groups of your cloud server provider (such as Alibaba Cloud, Tencent Cloud, and AWS) and the server's internal firewall (such as `iptables` or `ufw`), and consider closing rules for the old port.

If the user list is the gatekeeper, then the authentication method is the lock. Password authentication is relatively vulnerable due to its potential for brute-force attacks or sniffing, while key authentication based on public-key cryptography is much more secure. Implementing key authentication first requires generating a key pair (public and private keys) on the local client:

ssh-keygen -t ed25519 -C "your_email@example.com"

By default, this will generate `id_ed25519` (the private key, which must be kept strictly confidential) and `id_ed25519.pub` (the public key) in the `~/.ssh/` directory. Next, the public key needs to be deployed to the target user's home directory on the server. A simple method is to use the `ssh-copy-id` command, which automatically handles file creation and permission settings:

ssh-copy-id -p your_port_number admin@your_server_IP

After deployment, to completely disable high-risk password logins and force all users to use key authentication, you can configure the following in the server's SSH configuration:

PasswordAuthentication no
ChallengeResponseAuthentication no

Finally, setting firewall rules at the network layer constitutes the final barrier for access control. For Hong Kong cloud servers, this typically involves two layers: first, the "Security Group" provided by the cloud platform console, which is an outer virtual firewall; and second, the software firewall within the operating system, such as `ufw` (Uncomplicated Firewall). In the Security Group, policies should be set to only allow access to the SSH port from specific management IP address ranges (such as public IPs from the company's office network), and strictly deny access to the entire network via `0.0.0.0/0`. Internally, the same strategy can be easily achieved using `ufw`:

sudo ufw allow from 203.0.113.0/24 to any port 58222
sudo ufw enable

This command only allows connections from the `203.0.113.0/24` IP range to access port 58222, and then enables the firewall.

In summary, managing SSH access to Hong Kong cloud servers is a layered project. From modifying the user list and basic parameters defined in `sshd_config`, to switching to key authentication to strengthen identity verification, and then configuring cloud security groups and local firewalls to implement network layer filtering, each step is interconnected, jointly building a defense-in-depth system.