SSH Brute Force Mitigation: Stop the Attacks Now

SSH Brute Force Attacks – They're Annoying, Let's Fix It

Yeah, that SSH brute force alert is a pain. I get it. Had a client last month whose entire server nearly went down because the load spiked from thousands of failed login attempts. But here's the good news: you can stop this in under 10 minutes.

The Real Fix

Skip the manual blocking. You'll go crazy trying to ban IPs one by one. The real fix is fail2ban. It's a tool that watches your SSH logs and bans IPs after too many failures. Here's how to set it up on Ubuntu or Debian:

sudo apt update
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Then, edit the local config file:

sudo nano /etc/fail2ban/jail.local

Look for the [sshd] section. Set enabled = true, maxretry = 3, bantime = 3600 (one hour), and findtime = 600 (10 minutes). Save and reload:

sudo systemctl restart fail2ban

That's it. Now three failed attempts from the same IP in 10 minutes gets that IP banned for an hour. No more load spikes. No more alerts.

Why This Works

Fail2ban watches your SSH logs in real time. When it sees a pattern — like repeated failed logins — it adds an iptables rule to drop packets from that IP. This stops the attack at the network level, before it ever hits SSH. The attacker gets a timeout and moves on. My client's server went from 99% CPU to 5% after we set this up. Night and day.

Less Common Variations

Sometimes fail2ban isn't enough. Here's what else might be happening:

• DenyHosts: An older tool that does the same thing as fail2ban. If you're on an older distro like CentOS 6, you might see denyhosts instead. It works but I prefer fail2ban — it's more flexible.
• Whitelist your own IPs: In fail2ban, add ignoreip = 192.168.1.0/24 203.0.113.5 in the [DEFAULT] section. I once locked myself out of a client's server because I forgot this. Don't be that guy.
• SSH on a non-standard port: Changing from port 22 to something like 2222 reduces noise by 90%. The script kiddies usually scan only default ports. Update your fail2ban port setting to match.

If you see sshd[1234]: Bad protocol version identification, that's a different beast — it's usually a misconfigured client, not an attack. But if it repeats, still ban it.

Prevention – Keep It Locked Down

After the fix, don't stop there. Here's how to make sure it never happens again:

1. Use key-based authentication only. Disable password logins entirely. Edit /etc/ssh/sshd_config and set PasswordAuthentication no. Then restart SSH: sudo systemctl restart sshd.
2. Limit who can SSH. Add AllowUsers yourusername in the SSH config. Blocks everyone else.
3. Install a monitoring tool like OSSEC or Wazuh. They'll alert you if something slips through.
4. Keep your system updated. Run sudo apt update && sudo apt upgrade weekly. Critical SSH vulnerabilities pop up — like the Terrapin attack in 2023. Patch fast.

One last thing: test your setup. Try logging in with a wrong password three times from another machine. Then check sudo fail2ban-client status sshd. You'll see the banned IP list. If it works, you're golden.

Got persistent attacks from the same subnet? Add a firewall rule to block the whole range. But normally, fail2ban handles it. Now go grab a coffee — your server's safe.