Fail2ban Does Not Secure SSH, and Its Own README Says So

Install fail2ban, watch the ban counter climb, feel safer. That sequence is why the tool is on almost every server, and it is also why a lot of those servers are less protected than their owners believe.

The clearest statement of the problem is not in a critique of fail2ban. It is in fail2ban’s own README.

What it actually does

The mechanism is simple and it works. Fail2ban scans log files like /var/log/auth.log and bans IP addresses conducting too many failed login attempts. It does this by updating system firewall rules to reject new connections from those IP addresses, for a configurable amount of time.

It ships ready to read many standard log files, including those for sshd and Apache, and it can be pointed at any log file of your choosing, for any error you wish. Since version 0.10 it also matches IPv6 addresses.

That is a genuinely useful piece of infrastructure. A server exposed to the internet collects thousands of automated login attempts a day, and fail2ban turns that flood into a trickle.

The sentence the project puts in its own README

Here is where the tool is more honest than most of the advice about it:

Though Fail2Ban is able to reduce the rate of incorrect authentication attempts, it cannot eliminate the risk presented by weak authentication.

Read what that concedes. Fail2ban acts on the rate. It does not act on the risk. Those are different quantities, and conflating them is the whole mistake.

If your SSH server accepts a password, an attacker needs to guess it. Fail2ban slows the guessing to a crawl and makes a naive brute force impractical. But the door still opens for anyone who has the password, whether they guessed it, phished it, bought it in a credential dump, or pulled it from a reused login on an unrelated breached site. None of those paths involves repeated failures, so none of them trips a ban.

What the project tells you to do instead

The README does not stop at the warning. It names the alternative:

Set up services to use only two factor, or public/private authentication mechanisms if you really want to protect services.

That is the actual fix, and it is a change in kind rather than a change in degree. A server that accepts only key-based authentication cannot be brute forced at all, because there is nothing to guess. The attack surface is not narrowed, it is removed.

Notice the word only. Adding a key while leaving password authentication enabled changes nothing about the risk, because the weakest accepted method is the one that defines your exposure. The setting that matters is disabling password authentication, not adding a key alongside it.

So should you run it

Yes, and for the right reason.

Keep it for the noise. Logs you can actually read are worth a lot. When failed authentication attempts drop from thousands a day to a handful, an anomaly becomes visible instead of being buried. That is a real operational benefit and a good argument for the tool.

Do not count it as your SSH security. If a security review of your server ends at “fail2ban is installed”, the review stopped one step too early. The question that decides your exposure is whether password authentication is still accepted.

Watch what it costs you. Bans apply to addresses, and addresses are shared. A mistyped password on a corporate or mobile network can lock out everyone behind that address, including you. Fail2ban is one of the more common ways administrators lock themselves out of their own servers.

The honest summary

Fail2ban does exactly what it says: it reduces the rate of failed authentication attempts by banning noisy addresses at the firewall, for a configurable time, based on your logs.

Its own documentation is explicit that this cannot eliminate the risk presented by weak authentication, and that services you really want to protect should use two factor or public and private key mechanisms. Those two sentences are worth more than most hardening checklists.

Run fail2ban to keep your logs legible. Disable password authentication to keep your server. They are not substitutes for each other, and only one of them changes what an attacker is able to do.

The description of fail2ban’s behaviour, the quoted limitation about weak authentication, the recommendation to use two factor or public and private key authentication, and the IPv6 support since version 0.10, are taken from the fail2ban project’s own README, checked at the time of writing. Configuration details vary by distribution; check your own package’s documentation before relying on a specific path or default.