Harden SSH without locking yourself out

SSH changes can lock you out. Keep the current session open and prove a second connection before closing it.

The order of operations matters more than the settings themselves. Confirm key login works first. Only then remove the weaker paths.

Put the change in a drop-in file

On Ubuntu, sshd reads /etc/ssh/sshd_config plus every fragment in /etc/ssh/sshd_config.d/. Keep your hardening in its own file:

# /etc/ssh/sshd_config.d/90-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

After key login works, disable direct root login and password authentication when the environment supports it. Restrict users where useful with AllowUsers dana marco, and keep provider-console recovery ready.

Validate before reloading

Validate the configuration before reload and never experiment first on the only production path:

sudo sshd -t

No output means the syntax is valid. Then check what the daemon will actually enforce. Test the effective daemon configuration, not only the edited file — included configuration fragments can override a setting and make a clean-looking file provide false confidence:

sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication'
# permitrootlogin no
# passwordauthentication no

Now reload, and open a second session from another terminal before closing the first:

sudo systemctl reload ssh

If the second login works, the change is safe. If it fails, your original session is still open and you can revert.

Prove the lockdown

Force a password attempt and confirm the server refuses it:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [email protected]
# [email protected]: Permission denied (publickey).

Disabling passwords before testing key login can leave the server unreachable. Keeping an open session helps, but a provider console is the independent recovery path. Confirm you can actually log into that console before you need it at 3am.

Validate the SSH configuration and open a second key-only session before reloading. Test password and root login failures, then prove the provider recovery path remains available.