Harden your SSH configuration

Once key-based login works, you can turn off the weakest options: direct root logins and password guessing. This guide makes SSH stricter and shows how to test each change without locking yourself out.

Before you begin

• Working key-based login for your sudo user. Confirm it before you change anything, as described in the SSH key guide.
• A second terminal window already connected to the server, to keep as a backup session.
• Your provider's browser console, or LightServe support via chat or email, in case you need a way back in.

Step 1: Check the current effective settings

The sshd -T command prints the settings SSH is actually using, after it has read every configuration file. The grep filter shows only the lines you care about:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'

permitrootlogin yes
passwordauthentication yes
pubkeyauthentication yes

Step 2: Look at the drop-in folder

Ubuntu reads extra SSH settings from files in /etc/ssh/sshd_config.d/. These are read in alphabetical order, and when the same setting appears twice, the first value wins. Cloud images often include a file such as 50-cloud-init.conf that enables password logins, so list the folder:

ls /etc/ssh/sshd_config.d/

Name your file 10-hardening.conf. Because 10- sorts before 50-, your settings take priority.

Step 3: Write the hardening settings

Create the new file in the nano editor:

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

Enter these lines exactly, then save with Ctrl+O and exit with Ctrl+X:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

PermitRootLogin no blocks direct root logins over SSH. PasswordAuthentication no turns off password logins. KbdInteractiveAuthentication no closes a second route to password prompts. PubkeyAuthentication yes keeps key logins working. MaxAuthTries 3 limits failed attempts per connection.

Step 4: Check the configuration for errors

Before applying anything, test the syntax. The -t flag checks the configuration and prints nothing if it is valid:

sudo sshd -t

If there is a problem, the error names the file and line number. Fix it and run the test again.

Step 5: Confirm the new effective settings

Run the Step 1 check again. The values should now have changed:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'

permitrootlogin no
passwordauthentication no
pubkeyauthentication yes

Step 6: Reload SSH without ending your sessions

systemctl reload tells the SSH service to pick up the new settings. Existing connections, including your backup terminal, stay open:

sudo systemctl reload ssh

Step 7: Test from a new terminal

Open a third terminal and log in as your sudo user. It should work with your key:

ssh alex@203.0.113.10

Now try logging in as root. It should be refused:

ssh root@203.0.113.10

root@203.0.113.10: Permission denied (publickey).

Only close your original sessions after both tests behave as expected.

Troubleshooting

• You are locked out after the reload. Use your provider's browser console, or contact LightServe support via chat or email. Then fix the key setup from the key guide before turning password logins off again.
• sshd -t reports an error. The message names the file and line. Common causes are a typo in a setting name or a missing space. Correct it and run the test again.
• The password prompt still appears. A file with higher priority may be overriding yours. Run sudo sshd -T | grep passwordauthentication to see the active value, then list /etc/ssh/sshd_config.d/ and look for files that sort before 10-.
• Reload seemed to do nothing. Check the service with sudo systemctl status ssh --no-pager, which should show active (running).

Next steps

Your SSH door is much harder to force open. Next, install Fail2ban to block the bots that keep knocking on it.