How to harden SSH configuration on a fresh Ubuntu Cloud VPS

Secure your new Ubuntu 24.04 server by disabling root login, enforcing key-based authentication, and restricting access to specific IP ranges using the OpenSSH server configuration. These steps apply to Ubuntu 24.04 LTS with OpenSSH 9.6p1 and require sudo privileges to modify system files. Follow the instructions below to reduce the attack surface of your cloud instance immediately after installation.

Prerequisites

• Ubuntu 24.04 LTS (Noble Numbat) or later
• Access to the server via a working SSH key or password
• Sudo privileges or root shell access
• A valid SSH key pair generated for non-root access (recommended)

Step 1: Backup the current SSH configuration

Before making changes, create a backup of the existing sshd_config file. This ensures you can restore the original settings if a mistake occurs during configuration.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%F)

You will see a success message if the file is copied successfully, or nothing if the command runs silently.

Step 2: Edit the SSH daemon configuration file

Open the sshd_config file using a text editor like nano or vi. Use nano for easier editing on the command line.

sudo nano /etc/ssh/sshd_config

Locate the line starting with PermitRootLogin. Change its value from yes to no to prevent direct root access. This is a critical security measure to mitigate brute-force attacks targeting the root account.

PermitRootLogin no

Find the line PasswordAuthentication and set it to no. This forces all logins to use public key authentication only, which is significantly more secure than passwords.

PasswordAuthentication no

Locate PubkeyAuthentication and ensure it is set to yes. This explicitly enables key-based login, which is required for the previous step to work correctly.

PubkeyAuthentication yes

Search for the line AllowUsers. If it does not exist, add it near the bottom of the file. This directive restricts SSH access to specific system users only. Replace your-user with the actual username of your account.

AllowUsers your-user

Find the PermitEmptyPasswords setting and ensure it is set to no. This prevents accounts with no password from logging in, blocking automated password guessing attacks.

PermitEmptyPasswords no

Locate the ClientAliveInterval setting. Set it to 300 seconds (5 minutes). This forces the server to send a keep-alive message to idle clients, disconnecting them if they do not respond.

ClientAliveInterval 300

Set ClientAliveCountMax to 2. This defines how many keep-alive messages are sent before the connection is terminated. Combined with the previous setting, this drops idle connections after 10 minutes of inactivity.

ClientAliveCountMax 2

Search for the X11Forwarding setting and set it to no. Disabling X11 forwarding prevents potential attacks that exploit graphical protocol vulnerabilities.

X11Forwarding no

Save the file by pressing Ctrl+O, then press Enter to confirm the filename. Exit the editor by pressing Ctrl+X.

Step 3: Restrict SSH access to specific IP ranges

By default, the AllowUsers directive accepts all usernames. To restrict access to specific IP addresses, use the AllowGroups directive or combine it with DenyUsers. However, a more robust method for IP-based restriction is using the AllowTcpForwarding and AllowAgentForwarding settings to control what happens after login. For strict IP filtering, you must use the AllowUsers directive with the IP keyword if supported, or rely on the firewall. Since Ubuntu uses firewalld or ufw, the best practice is to use AllowUsers with specific usernames and rely on the firewall for IP blocking.

Alternatively, you can use the Match Address block to apply settings per IP. Add this block to the sshd_config file:

Match Address 192.168.1.0/24
    PermitRootLogin prohibit-password
    PasswordAuthentication yes
    PubkeyAuthentication yes

This example restricts the settings to the 192.168.1.0/24 subnet. For a single IP, replace the CIDR block with the specific IP address.

Step 4: Set up a firewall to block unauthorized SSH access

Configure UFW (Uncomplicated Firewall) to allow SSH only from your office or home IP address. Replace Your-Office-IP with your actual public IP address.

sudo ufw allow from Your-Office-IP to any port 22 proto tcp

Deny SSH access from all other IP addresses by default. UFW does this by default, but you can explicitly deny it to be clear.

sudo ufw deny from any to any port 22 proto tcp

Allow established connections to pass through. This ensures that once you connect, your session remains open.

sudo ufw allow established

Enable the firewall with the following command. If the firewall is already active, it will report that the profile is already active.

sudo ufw enable

You will see a prompt asking for confirmation. Type y and press Enter.

Check the firewall status to ensure the rules are applied.

sudo ufw status verbose

The output will list the active rules and the default policies for incoming and outgoing connections.

Step 5: Restart the SSH service

Apply the configuration changes by restarting the OpenSSH daemon. This reloads the settings without dropping existing connections immediately, but new connections will use the new rules.

sudo systemctl restart ssh

Verify that the service is running and active.

sudo systemctl status ssh

The status output should show active (running) in green. If the service fails to start, check the logs with journalctl -u ssh -n 50 for errors.

Verify the installation

Test the new configuration from a different machine or using a second terminal window. Attempt to log in using the root account. The connection should be rejected immediately.

ssh root@your-server-ip

You should see a message like Permission denied, please try again or Connection refused. If you have not set up a firewall, the connection may be refused by the server itself due to the PermitRootLogin no setting.

Now attempt to log in using your specific user account and SSH key.

ssh your-user@your-server-ip

The connection should succeed. If you are using a password for this user, it should also work, but key authentication is preferred. If the connection fails, check the logs on the server with sudo tail -f /var/log/auth.log to see the reason for rejection.

Troubleshooting

If you lock yourself out after making changes, you cannot log in via SSH. In this case, access the server via the cloud provider's console (VNC or serial console) and restore the configuration manually. Edit the sshd_config file directly in the console to re-enable root login temporarily.

PermitRootLogin yes

Restart the SSH service again to regain access.

sudo systemctl restart ssh

Once logged in, re-apply the secure settings and ensure your SSH key is accessible. If you are unsure about a specific setting, consult the man page for sshd_config using man sshd_config.

If the firewall blocks your connection, verify the UFW status with sudo ufw status. Ensure your IP address is listed in the allowed rules. If you made a typo in the IP address, the connection will be blocked. Double-check the AllowUsers directive to ensure your username is spelled correctly.

Ensure that your SSH key is added to the authorized_keys file for your user. If the key is missing, the login will fail even if the configuration is correct. Add the key using cat ~/.ssh/id_rsa.pub | ssh your-user@your-server-ip 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'.