Hi there, guest! If you have an account, then please sign in or register in order to see more.
How to Harden SSH and Stop Brute-Force Attacks
Updated 7 October 2026
10 min read
ESAGAMES Team
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.
Use key-based login and disable password authentication entirely — with no password to guess, brute-force attacks become impossible. Add fail2ban to ban repeat offenders and keep your logs clean.
Should I change the default SSH port?
It is optional and not real security on its own, since a determined attacker will still find the port. But moving off port 22 dramatically cuts the noise from automated scanners. Keep the real locks (keys, no root login) in place regardless.
Is it safe to disable password login for SSH?
Yes, and it is strongly recommended — but only after you have set up and tested a working SSH key. Once keys work, disabling passwords ends the entire category of brute-force attacks against you.
BepInEx, QoL, building and content mods — the best Valheim mods to run on a dedicated server this year, with a starter pack and sync rules that stop join failures.
Super Structures, Spyglass, Cryopods and more — the best ARK mods to run on a server this year, with load order and the ASE-vs-ASA differences that trip people up.
Two critical PHP flaws leaked before their fix and can lead to remote code execution. Fixed versions, who is affected and exactly what to do.
Action required
Let's talk about privacy.
We use essential cookies to keep checkout, login sessions and security flows working. Optional cookies help us understand performance, remember interface choices and enable external support widgets only when you allow them.
