On almost every internet-facing server, SSH is the single most-attacked service - automated bots try to guess logins around the clock. The good news: a handful of changes make those attacks completely futile. Here is how to harden SSH properly, step by step.
Quick answer
To harden SSH, log in with keys only and set PasswordAuthentication no, disable direct root login (PermitRootLogin no), limit who can log in with AllowUsers, and add fail2ban to ban brute-force IPs. Changing the port only cuts log noise — keys are what actually stop the attacks.
Why SSH is such a target
SSH gives full command-line control of a server, so it is the prize every credential-guessing bot is after. Leave it on the default port with password login enabled and your logs will fill with thousands of attempts a day - you may already have seen too many authentication failures. The fix is not to hide; it is to make guessing impossible.
1. Use SSH keys, not passwords
This is the single biggest win. An SSH key pair replaces a guessable password with a cryptographic key that is effectively impossible to brute-force. Generate a key, install the public half on the server, confirm it works - then move on to disabling passwords entirely. If the connection ever gets refused outright while you are setting this up, see SSH connection refused.
2. Disable password authentication
Once your key works, turn off password login in the SSH config. From that point, no amount of guessing can get in, because there is no password to guess. This single change ends the entire category of brute-force attacks against you.
3. Disable direct root login
Do not let anyone SSH in as root directly. Log in as a normal user and elevate with sudo when needed. This means an attacker has to know which user to target as well as hold its key - and it keeps a clear audit trail of who did what.
4. Consider changing the port
Moving SSH off port 22 is not real security - a determined attacker will find it - but it does dramatically cut the noise from automated scanners that only check the default port. Treat it as reducing log spam, not as a lock. Keep the real locks (keys, no root) in place regardless.
5. Add brute-force protection
Run fail2ban or similar to automatically ban IPs that rack up failed logins - see how to install and use fail2ban. Combined with key-only auth, this keeps your logs clean and your server off the radar of opportunistic bots.
6. Keep SSH patched
SSH software itself occasionally has serious bugs - the 2024 regreSSHion flaw (CVE-2024-6387) was an unauthenticated remote code execution in OpenSSH, a reminder that even the front door needs patching. Keep your system updated so a known hole is never left open. See more in famous Linux vulnerabilities.
How to check your SSH setup is actually locked down
Do not just assume the config took - verify it. Open a fresh terminal (do not close your working session) and try logging in with a password; it should be refused. Try SSHing in as root directly; it should also fail. Check your auth log for a sudden drop in failed-login noise once fail2ban and key-only auth are both active - that quiet log is the real confirmation everything is working.
Key-only login plus no root access turns SSH from your biggest liability into a non-event. The bots keep knocking; the door simply has no keyhole for them.
The quick checklist
- Key-based login set up and tested.
- Password authentication disabled.
- Direct root login disabled.
- Port changed to cut scanner noise (optional).
- fail2ban or similar banning repeat offenders.
- System kept patched and up to date.
If you ever lock yourself out while tightening things, the usual culprits are covered in SSH connection refused and permission denied (publickey). This guide is part of the broader Linux VPS hardening checklist.