Block SSH Brute‑Force Attacks With SSHGuard
If your server’s been getting hit by automated login attempts and you’re tired of sifting through log files for the same “invalid user” errors, SSHGuard can do the heavy lifting in seconds.
It watches /var/log/auth.log (or whatever log you use) and automatically drops IPs that make too many failed attempts—no extra scripts, no manual iptables entries.
Why You Should Use SSHGuard
SSHGuard is lightweight compared to the likes of Fail2Ban. It hooks straight into your existing firewall (iptables, firewalld, or ufw) and only bans when it’s actually needed.
I once had a hobby server that was suddenly flooded with login attempts from a botnet in the middle of the night; after installing SSHGuard my logs stopped filling up, and the IP list on the console grew to three addresses in less than two minutes—proof that it works fast.
If you already run Fail2Ban and enjoy its more granular filters, skip this. If your server is small or you just want a “watch‑and‑ban” approach, SSHGuard is a sweet spot.
1. Install SSHGuard
sudo apt-get update && sudo apt-get install sshguard # Debian/Ubuntu # or sudo yum install sshguard # CentOS/RHEL/Fedora
Installing via the package manager pulls in the latest security patches and ensures that sshguard starts automatically as a system service.
2. Verify the Service Is Running
systemctl status sshguard.service
You should see “active (running)”. If not, start it:
sudo systemctl enable --now sshguard
SSHGuard runs in the background; if it’s not running, you’re basically blind to attacks.
3. Configure What Counts as a Brute‑Force
Open /etc/sshguard.conf:
sudo nano /etc/sshguard.conf
Set these key parameters:
# Maximum failed login attempts per IP before banning MAX_RETRIES=3 # How long to keep an IP banned (seconds) BANNED_TIME=86400 # 24 hours # Which firewall backend to use BACKEND=iptables
The default values are a good starting point. Adjust MAX_RETRIES if you see legitimate users being blocked, or extend BANNED_TIME for more aggressive protection.
4. Test It With a Simulated Brute‑Force
Run a quick brute‑force attempt from your own machine:
hydra -l user -P /usr/share/wordlists/rockyou.txt ssh://your.server.ip
Watch /var/log/auth.log and the iptables rules:
tail -f /var/log/auth.log & sudo iptables -L INPUT --line-numbers
Within a few failed attempts, you should see an entry like:
DROP all -- <attacker-ip> anywhere
Testing confirms that SSHGuard is parsing the log correctly and that your firewall is actually blocking traffic.
5. Make Your iptables Rules Persistent (Optional)
If you’re on a distro that doesn’t keep iptables rules across reboots, install iptables-persistent:
sudo apt-get install iptables-persistent
During installation, choose “Yes” to save current rules.
SSHGuard will add its bans to this file automatically.
Without persistence, you’d have to reinstall SSHGuard or manually re‑apply the bans after a reboot—a hassle that defeats the point.
6. Keep Your System Updated
sudo apt-get update && sudo apt-get upgrade
Or on CentOS:
sudo yum update
An up‑to‑date OS and firewall mean fewer vulnerabilities for the brute‑force bots to exploit.
7. Optional: Combine With Key‑Based SSH Only
If you’re still allowing password logins, consider disabling them altogether:
sudo nano /etc/ssh/sshd_config
Set:
PasswordAuthentication no PermitRootLogin prohibit-password
Then restart SSH:
sudo systemctl reload sshd
Key‑based authentication is virtually immune to brute force. SSHGuard becomes a safety net rather than the primary defense.
If you’re running a larger environment or need more advanced filtering (like geo‑blocking), you might want Fail2Ban or custom scripts. For a quick, low‑maintenance fix that keeps your logs tidy and your IP tables uncluttered, give SSHGuard a try.
