How to Harden SSH and Stop Brute-Force Attacks

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.

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.

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. 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.

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. This guide is part of the broader Linux VPS hardening checklist.