Harden SSH without locking yourself out

SSH hardening is safe only after the replacement access path works. Confirm again that deploy can log in with its key and run sudo. Keep that session open and keep the recovery console available.

Create a small drop-in instead of rewriting the package configuration:

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

Add:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

This removes direct root login and password-style remote login. It does not disable your working public-key login.

Validate the complete configuration before asking the service to read it:

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

sshd -t should print nothing and exit successfully. The effective configuration should show root and password authentication disabled while public-key authentication remains enabled.

Only then reload SSH:

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

A reload preserves existing connections. Open a third terminal and verify a fresh deploy login. Also verify that root login is rejected:

ssh -i ~/.ssh/digitalocean_notes deploy@203.0.113.10
ssh -i ~/.ssh/digitalocean_notes root@203.0.113.10

The first should work and the second should fail.

A common failure is a typo or a setting in another drop-in that wins earlier. That is why both sshd -t and sshd -T matter: one checks syntax, while the other shows effective values.

If a fresh deploy login fails, keep the existing session open. Move the new file aside, validate again, and reload:

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

If every network session is gone, repair the file from the recovery console. Your action is to complete both positive and negative login tests before closing any earlier session.