SSH Hardening Checklist for a Production VPS
A practical SSH hardening checklist for a self-hosted VPS: keys only, no root login, non-standard config, and the settings that actually stop brute-force attacks.
The fastest way to secure a new VPS is to fix SSH first, because SSH is the front door and the internet knocks on it constantly. Within minutes of a fresh box coming online, bots are trying root with common passwords. The good news is that hardening SSH is a short checklist, it takes ten minutes, and once it is done the brute-force noise stops mattering. I do this on every box in my portfolio before I install anything else, because a compromised server is not a recoverable problem, it is a rebuild.
Turn off password authentication entirely
This is the single most important change. As long as passwords are accepted, every bot on the internet can keep guessing, and humans pick guessable passwords. Switch to key-based authentication only and the guessing game ends: without your private key, there is nothing to brute force.
- Generate a strong key pair, ed25519 is the modern default.
- Add your public key to the server's authorized keys.
- Set
PasswordAuthentication noandChallengeResponseAuthentication noin the SSH config. - Confirm you can log in with the key before you close your existing session, so you never lock yourself out.
Once passwords are off, the vast majority of attacks against your box become impossible, not just harder. This is the change that does the most work.
Stop root from logging in directly
Never let root log in over SSH. Root is the account every attacker targets because it exists on every box and holds every permission. Set PermitRootLogin no and log in as a normal user, then escalate with sudo when you need to.
This does two things. It removes the one username an attacker can assume exists, and it gives you an audit trail: actions run through sudo are attributable to a user instead of an anonymous root session. On a fleet, knowing who did what matters, and it is the same instinct behind wanting servers that cannot be held hostage: control and accountability at every layer.
Lock down the SSH config
A handful of config settings close the remaining easy doors.
AllowUsersorAllowGroups: whitelist exactly who may connect, so an attacker cannot use some service account you forgot about.MaxAuthTries 3: drop connections that fail a few times instead of letting them keep trying.LoginGraceTime 20: do not hold half-open connections that guessers can pile up.Protocol 2: only the modern protocol, never the ancient one.
Changing the port from 22 is optional and does not add real security, but it does cut log noise dramatically, which makes the real signals easier to see. Treat it as noise reduction, not a defense.
Add a brute-force ban and a firewall
Even with passwords off, you do not want endless failed attempts hammering the box. A tool like fail2ban watches the auth log and temporarily bans IPs that fail repeatedly, which trims the noise and stops the most aggressive scanners. I cover when that is enough and when a network edge does more in fail2ban vs Cloudflare for brute force.
Underneath that, a firewall should allow only the ports you actually serve. SSH, HTTP, HTTPS, and nothing else exposed to the world. Everything internal, like your database, should never be reachable from the public internet. Setting that up is its own short job, covered in configuring UFW on a VPS. The firewall is the backstop: even if a service misbehaves, the port is simply not open.
Keep the box patched
Hardening SSH once is not the finish line. The OpenSSH package, like everything else, gets security fixes, and an unpatched box slowly rots into a target. Turn on automatic security updates so the base system stays current without you remembering to run updates. A hardened config on an unpatched server is a strong lock on a rotting door.
I run this exact checklist on every VPS in my portfolio, hosted through HostSSH, and the whole thing takes about ten minutes per box. Keys only, no root, tight config, a ban tool, a firewall, and automatic patches. Do it before you deploy anything. The front door is the first thing attackers try and the cheapest thing you can fix.