Password auth off isn't the same as SSH locked down
"Disable password authentication" is the most repeated piece of SSH hardening advice, and it's correct as far as it goes: key-only access removes the single biggest class of brute-force and credential-stuffing attempts. But it's step one of a checklist, not the checklist, and a server that stops there still has real exposure left on the table.
The gaps that tend to get skipped are the ones that don't show up until something goes wrong: root login still enabled as a fallback, no rate limiting on connection attempts, and no visibility into who's actually trying to get in.
What a properly hardened setup includes
Beyond key-only auth, a locked-down SSH configuration covers:
- Root login disabled outright (PermitRootLogin no), forcing a named user plus sudo for any privileged action
- fail2ban or an equivalent watching auth logs and banning repeat failed attempts automatically
- A non-default port, which won't stop a targeted attacker but does cut the volume of noise from automated scans
- Idle session timeouts (ClientAliveInterval / ClientAliveCountMax), so an unattended open session isn't a standing door
- SSH access restricted by firewall or security group to known IP ranges wherever that's practical
- Key rotation and a real offboarding process, so a former employee's key isn't quietly still valid
The mistake that undoes all of it
The most common way a hardened SSH config gets quietly reopened is a 'temporary' exception: password auth flipped back on for one contractor, a firewall rule opened to 0.0.0.0/0 to debug something and never closed, a shared key that was supposed to be rotated after a project ended. None of these show up as a breach immediately, they just sit as latent risk until they're found, ideally by you in an audit rather than by someone else.