Hardening an SSH server without locking yourself out

Goal

Reduce an SSH server's exposure to guessed passwords, stolen agents and misconfiguration, while keeping a guaranteed way back in during the change.

Prerequisites

Root or sudo on the host, a key pair on the administrator's machine (ssh-keygen -t ed25519 with a passphrase), the public key already in ~/.ssh/authorized_keys of the account that will be used, and an out-of-band console (cloud provider console, IPMI) known to work.

Steps

1. Open a second SSH session and leave it open for the whole procedure; a live session survives a restart of sshd and lets you undo a mistake.
2. Confirm key login works in a fresh session (ssh -o PasswordAuthentication=no user@host).
3. Edit /etc/ssh/sshd_config or a file in sshd_config.d/: PasswordAuthentication no, KbdInteractiveAuthentication no (its default is yes, per sshd_config(5)), PermitRootLogin no (or prohibit-password where root keys are unavoidable), PubkeyAuthentication yes.
4. Limit who may log in with AllowUsers or AllowGroups; for automation accounts, add a Match User block with ForceCommand, AllowTcpForwarding no and PermitTTY no.
5. Tighten the pre-authentication window: MaxAuthTries 3 (default 6), LoginGraceTime 30 (default 120 seconds), and PerSourcePenalties if the server version supports it.
6. Disable what is not used: X11Forwarding no, AllowAgentForwarding no where no one needs it (the manual notes this only helps if users also lack shell access).
7. Run sshd -t to validate the file, then restart or reload the service and log in from a third session before closing the second.
8. On the client side, use ProxyJump to reach hosts behind a bastion instead of ForwardAgent; ssh(1) warns that anyone able to bypass file permissions on the remote host can use a forwarded agent. If forwarding is unavoidable, load keys with ssh-add -c so every use asks for confirmation.
9. Record the change and the fingerprint of the server's host key in the runbook.

Expected result

Password guessing yields nothing, root cannot be targeted directly, only listed accounts exist as targets, and the administrator can still log in from the tested key. journalctl -u ssh (or sshd, depending on the distribution) shows failed attempts being cut off after three tries.

Limits and test basis

Distribution packages ship their own defaults and drop-in files; sshd_config(5) states that the first obtained value for a keyword is used, and that Include globs are expanded in lexical order, so check the effective configuration with sshd -T. This checklist covers sshd settings only; network-level limits (firewall, port knocking, fail2ban-style banning) and two-factor authentication are separate decisions. Option names and defaults are taken from the cited manual pages; no measurement is claimed.