Four methods — from basic SSH hardening to automated detection. Real commands you can run today on Ubuntu, Debian, CentOS, and RHEL.
An SSH brute force attack is when an automated bot tries thousands of username and password combinations against your server's SSH port (usually 22). The attacker doesn't need to know anything about your server — they scan entire IP ranges and try default credentials like root:admin, root:password, and ubuntu:ubuntu.
Based on Defensia telemetry across 9 production servers, the average Linux VPS receives over 4,200 SSH attack attempts per day. A newly deployed server gets its first attack within 22 minutes. On Ubuntu, these appear in /var/log/auth.log; on CentOS and Rocky Linux, check journalctl -u sshd.
Apr 7 03:14:22 server sshd[4821]: Failed password for root from 185.220.101.7 port 43992 ssh2
Apr 7 03:14:23 server sshd[4821]: Failed password for root from 185.220.101.7 port 43992 ssh2
Apr 7 03:14:25 server sshd[4823]: Invalid user admin from 45.83.64.11 port 55120
Apr 7 03:14:25 server sshd[4823]: Failed password for invalid user admin from 45.83.64.11 port 55120 ssh2
Apr 7 03:14:28 server sshd[4825]: Invalid user test from 91.108.4.30 port 22180
Apr 7 03:14:29 server sshd[4825]: Disconnecting invalid user test 91.108.4.30 port 22180: Too many authentication failures
Apr 7 03:14:31 server sshd[4827]: Failed password for ubuntu from 103.145.13.90 port 34210 ssh2
… this repeats thousands of times per day
If any of those credentials succeed, the attacker gets full shell access. From there they install cryptominers, add SSH backdoors, or pivot to other servers on your network. Even if passwords are strong, the constant log noise and resource consumption from thousands of failed attempts degrades performance. SSH hardening is part of a broader process covered in our VPS security checklist.
Before adding any tools, harden your SSH configuration. These changes go in /etc/ssh/sshd_config and require an SSH restart to apply. This is your baseline — do this regardless of which blocking method you choose.
# Disable root login — use a regular user + sudo instead
PermitRootLogin no
# Disable password authentication — use SSH keys only
PasswordAuthentication no
# Limit authentication attempts per connection
MaxAuthTries 3
# Only allow specific users (replace with your username)
AllowUsers deploy
# Disable empty passwords
PermitEmptyPasswords no
# Set login grace time (seconds to complete auth)
LoginGraceTime 30
$ sudo sshd -t && sudo systemctl restart sshd
Warning: Before disabling password authentication, make sure your SSH key is already in ~/.ssh/authorized_keys. Otherwise you'll lock yourself out. Keep a second SSH session open while testing.
Limitations: SSH hardening reduces the attack surface, but it doesn't block attackers. They'll still pound your SSH port, filling your logs and consuming resources. You need active blocking for that.
Use iptables to limit the number of new SSH connections per IP. This blocks bots that open multiple connections in rapid succession. No additional software needed — iptables is built into every Linux kernel.
# Track new SSH connections
$ sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
-m recent --set --name SSH --rsource
# Drop if more than 4 attempts in 60 seconds
$ sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
-m recent --rcheck --seconds 60 --hitcount 4 --name SSH --rsource -j DROP
# Debian/Ubuntu
$ sudo apt install iptables-persistent
$ sudo netfilter-persistent save
# RHEL/CentOS
$ sudo service iptables save
Limitations: iptables rate limiting is a blunt instrument. It blocks by connection rate, not by analyzing actual authentication failures. A slow attacker (1 attempt per 20 seconds) will bypass it completely. It also doesn't provide any logging, alerting, or dashboard visibility. It protects SSH only — not web applications, email servers, or databases.
fail2ban monitors log files for authentication failures and temporarily bans offending IPs. It's the most widely used SSH brute force protection on Linux. Free and open source.
# Debian/Ubuntu
$ sudo apt update && sudo apt install fail2ban -y
# RHEL/CentOS
$ sudo yum install epel-release -y && sudo yum install fail2ban -y
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600
$ sudo systemctl enable fail2ban && sudo systemctl start fail2ban
$ sudo fail2ban-client status sshd
Limitations: fail2ban works, but it has real drawbacks for production servers:
No dashboard or web interface — you check status via CLI only (fail2ban-client status sshd)
Each service requires a separate jail configuration (SSH, nginx, Postfix, etc.)
No WAF — fail2ban cannot detect SQL injection, XSS, or path traversal in web logs
No malware scanning — it only watches log files for authentication failures
Regex-based pattern matching — adding new attack patterns requires writing and testing regex filters
No multi-server management — each server is configured independently
Uses individual iptables rules — performance degrades with thousands of banned IPs (vs. ipset)
No real-time alerts — you must check the server manually or build custom notifications
For a full comparison, see fail2ban vs Defensia.
Defensia is a Go-based agent that detects 15 SSH attack patterns automatically and blocks attackers within seconds. No configuration files, no regex, no jails — install with one command and it works immediately.
$ curl -fsSL https://defensia.cloud/install.sh | sudo bash
The agent auto-detects your SSH logs (auth.log on Debian/Ubuntu, secure on RHEL/CentOS, journald on EL8/EL9), starts monitoring immediately, and blocks attackers via ipset with support for 65,000+ concurrent bans.
Beyond SSH, the same agent provides a web application firewall (15+ OWASP attack types from nginx/Apache logs), malware scanner (64K+ hash signatures, 684 dynamic patterns), CVE scanning, and a real-time dashboard showing all events across all your servers.
Deep dive: SSH brute force protection details.
SSH hardening is a baseline — always do it regardless. The question is what you add on top for active blocking.
| Feature | SSH hardening | iptables | fail2ban | Defensia |
|---|---|---|---|---|
| Blocks brute force | No | Rate only | Yes | Yes (15 patterns) |
| Configuration needed | Edit sshd_config | CLI commands | Jail files | None |
| Install time | 2 min | 2 min | 5-10 min | 30 seconds |
| Web dashboard | No | No | No | Yes (real-time) |
| WAF included | No | No | No | Yes (15+ OWASP) |
| Malware scanner | No | No | No | Yes (64K+ sigs) |
| Multi-server | No | No | No | Yes |
| Alerts (Slack/email) | No | No | Email only | Yes (Slack/email/Discord/webhook) |
| Ban capacity | N/A | iptables limits | iptables limits | 65,000+ (ipset) |
| Price | Free | Free | Free | Free (1 server) |
Recommendation: always apply SSH hardening (Method 1) as your baseline, then add Defensia for active blocking and visibility.
Based on Defensia telemetry, the average Linux VPS receives over 4,200 SSH attack attempts per day. A fresh server gets its first attack within 22 minutes of going online. The most targeted usernames are root, admin, test, ubuntu, and postgres.
Yes. They write firewall rules independently and don't conflict. However, most users remove fail2ban after installing Defensia — it becomes redundant since Defensia detects more patterns, uses ipset for better performance, and adds a dashboard, WAF, and malware scanning that fail2ban cannot provide.
Changing the SSH port (e.g., to 2222) reduces automated scanning noise by about 90%, but it's security through obscurity — not real protection. Advanced scanners still find non-standard ports. It's a useful noise reduction step, but not a substitute for actual brute force blocking. Do it as a bonus, not as your primary defense.
Based on Defensia data: root (by far the most common), admin, test, ubuntu, user, oracle, postgres, deploy, git, and ftpuser. Attackers use dictionaries with thousands of username/password combinations, testing common defaults first before moving to less common entries.
Defensia reads auth.log in real time using a tail-follow watcher. When an IP triggers the detection threshold (configurable, default 5 failures), it's banned within seconds via ipset. The ban and event are sent to the dashboard simultaneously, so you see the attack and the block in real time.
Defensia telemetry data: aggregated from 9 production servers, 250K+ attacks analyzed (2025-2026)
OpenSSH documentation: sshd_config(5) manual page — https://man.openbsd.org/sshd_config
fail2ban documentation: https://www.fail2ban.org/wiki/index.php/Main_Page
iptables recent module: https://ipset.netfilter.org/iptables-extensions.man.html
NIST SP 800-123: Guide to General Server Security — https://csrc.nist.gov/publications/detail/sp/800-123/final
One command. Zero configuration. 15 SSH attack patterns detected automatically.
Free for 1 server. No credit card required.