If you’re running services exposed to the public internet, you’ll obviously need a way to remotely administer the machine. By far, the most common method is SSH, typically via OpenSSH. It is used on the vast majority of BSD and Linux systems.
One of the best improvements you can make to your SSH security model is to simply disallow password authentication entirely. A password can be guessed, leaked, or brute-forced. While an SSH private key could also be leaked or stolen, it is still widely considered to be the more secure and preferred option.
That said, there are situations where you may want or need to allow login from arbitrary machines. In those cases, requiring a private key may not be practical, since you would need to carry it with you everywhere, which isn’t always possible or convenient.
Basic SSH Hardening
First things first: do not allow anyone to log in as root using a password.
Really, you should not allow root login over SSH at all. But if you must allow it, then ensure it is key-only authentication.
If your server is exposed to the public internet, and especially if it listens on the default port 22, you can absolutely expect it to be hammered by bots and automated attacks. These will attempt logins constantly, probing for weak credentials.
They will also crawl your web services, checking endpoints and attempting to fingerprint your system. From that fingerprint, they can infer what vulnerabilities might apply. This is not hypothetical — expect hundreds or thousands of attempts per day.
Enter Fail2Ban
This is where Fail2Ban comes in.
Fail2Ban monitors logs for suspicious activity and reacts automatically. You define patterns (for example, repeated failed SSH logins), and when those patterns are matched, Fail2Ban takes action.
The most common setup is simple:
If an IP fails to authenticate 3 times, ban it at the firewall level.
Fail2Ban does this by inserting firewall rules (via iptables, nftables, or UFW depending on your system). Once triggered, traffic from the offending IP is dropped immediately.
This drastically reduces the effectiveness of brute-force attacks. Instead of allowing unlimited guesses, attackers get cut off almost instantly and must switch IPs to continue.
More Advanced Uses
You can go further if you want.
For example:
- Ban entire subnets instead of single IPs
- Aggressively block repeat offenders
- Target other services (nginx, mail, etc.)
You can even block large geographic regions if you map IP ranges, though that requires more care and maintenance.
Whitelisting (Very Important)
The opposite is also possible — and recommended.
If you have a static IP at home, work, or another server, you should whitelist it. This ensures you never accidentally lock yourself out.
Even if you are using key-based authentication, having a whitelist adds an extra layer of safety and peace of mind.
Debian Setup (Minimal and Clean)
Install Fail2Ban:
sudo apt update
sudo apt install -y fail2ban
Create a local configuration file (do not edit defaults):
sudo nano /etc/fail2ban/jail.local
Paste the following:
[DEFAULT]
# NEVER ban these IPs (add your own here)
ignoreip = 100.100.100.100 200.200.200.200# Ban settings
bantime = -1
findtime = 10m
maxretry = 3# Backend auto works fine on Debian
backend = auto# Use nftables (modern Debian) or iptables fallback
banaction = ufw
#nftables-multiport[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
If you are NOT using UFW, use this instead (this will always work on Debian)
Enable and start the service:
sudo systemctl enable fail2ban
sudo systemctl restart fail2ban
If using UFW, make sure it is enabled and allows SSH:
sudo ufw allow ssh
sudo ufw enable
Verify everything is working:
sudo fail2ban-client status
sudo fail2ban-client status sshd
What this configuration does:
- 3 failed SSH attempts results in a ban
- Ban is permanent (bantime = -1)
- Your IPs are never banned
- Firewall rules are handled via UFW (or iptables if you chose that route)
Final Thoughts
Fail2Ban is not a silver bullet, but it is an extremely effective first line of defense. It turns constant background noise from the internet into something manageable and largely harmless.
Combined with disabling password authentication, using SSH keys, and disabling root login, you end up with a setup that is simple, clean, and very difficult to attack in practice.
