Reduce authentication and network exposure

Every login method the server accepts is a door. Password login is a door bots try thousands of times a day. Root login leads straight to everything. Hardening is closing the doors nobody uses.

The order matters more than the settings. You close a door only after proving that another one works, and that the emergency exit works too. People who lock themselves out did the steps in the wrong order, not the wrong steps.

First, prove what you will rely on

Before changing anything, check three things:

1. Your personal key logs in: ssh notes-server 'id' works from a fresh terminal.
2. The provider console works. Open it, log in, close it. Now, not during the incident.
3. Nothing else depends on what you are removing. A backup script using a password? A colleague still on root? Ask.

Skipping step 2 is the classic mistake. The console is your break-glass access, the way in when SSH itself is broken. Test it while you do not need it.

Close the authentication doors

Add to the drop-in from the previous lesson:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers anna marco deploy

AllowUsers is the line that bites. Anyone not on it, including you if you forget yourself, is refused with a perfectly valid configuration. Read it twice. Then run the full sequence from the previous lesson: sshd -t, sshd -T | grep -iE 'password|permitroot|allowusers', reload, second session.

Watch each door stay shut

Now try the doors you closed, from a separate terminal. A password attempt:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

[email protected]: Permission denied (publickey).

The server did not even offer a password prompt. Only publickey remains. Root with your working key:

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

[email protected]: Permission denied (publickey).

A user not on the list, with a valid key installed, gets the same denial. On the server, journalctl -u ssh says User bob not allowed because not listed in AllowUsers. The client message is identical for all three. The server log tells them apart.

Close the network door too

Authentication is one layer. The other is who can reach port 22 at all. If your team connects from known addresses, let only those in:

sudo ufw allow from 198.51.100.7 to any port 22 proto tcp
sudo ufw delete allow 22/tcp
sudo ufw status numbered

[ 1] 22/tcp    ALLOW IN    198.51.100.7

Do this from a session that is already open, and test a new connection before you trust it. If you travel, or your home IP changes, a fixed allow list locks you out as effectively as a bad AllowUsers. Then the console is your only way back, which is why you tested it first.

Keep the evidence from all four tests: password denied, root denied, unlisted user denied, and a connection from outside the firewall rule timing out. Those four lines are what “hardened” means, not the config file.