Harden SSH without locking yourself out

Now we turn off root login and password login over SSH. Those two settings close the doors scanners hammer on all day. But they only make sense once the replacement door works, so check again that deploy can log in with its key and run sudo. Keep that session open. Keep the recovery console handy too.

Add a drop-in, don’t edit the main file

Ubuntu reads /etc/ssh/sshd_config and then every file in /etc/ssh/sshd_config.d/. A small file of your own in that directory is easier to review, and easier to remove when it breaks something. Create one:

sudoedit /etc/ssh/sshd_config.d/00-notes-hardening.conf

Put these three lines in it:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

The first blocks root over SSH. The other two block every kind of password prompt. None of them touches public key login, which is what you’re using right now.

Validate before you reload

Check the syntax, then check the values SSH will actually use:

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

sshd -t prints nothing when the config is valid. sshd -T prints the effective settings, and you want to see permitrootlogin no, passwordauthentication no, kbdinteractiveauthentication no and pubkeyauthentication yes.

The two commands catch different problems. -t finds typos. -T finds a setting in another drop-in that loads first and wins. Files in sshd_config.d apply in name order, and for most options the first value read is the one that sticks. That’s why this file starts with 00-.

Reload and test both ways

Only now reload the service:

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

A reload keeps your existing connections alive. Open a third terminal and try both a login that should work and one that should fail:

ssh -i ~/.ssh/digitalocean_notes [email protected]
ssh -i ~/.ssh/digitalocean_notes [email protected]

The first gives you a shell. The second ends with Permission denied (publickey). Both results matter. A hardening step you didn’t test negatively might not be doing anything.

If the deploy login fails

Don’t touch the session you kept open. From it, move the new file out of the way, validate, and reload:

sudo mv /etc/ssh/sshd_config.d/00-notes-hardening.conf /root/
sudo sshd -t && sudo systemctl reload ssh

Then read the file you moved and find the mistake. If every session is gone, fix the file from the recovery console instead.

Complete both the positive and the negative test before closing any earlier terminal. For more on how sshd reads its config, the SSH course has a lesson on changing it safely.