It's useful as part of a layered strategy. Your passwords still need to be secure enough that they can't be guessed easily. If they're easily brute-forced, fail

It's useful as part of a layered strategy. Your passwords still need to be secure enough that they can't be guessed easily. If they're easily brute-forced, fail2ban might slow things down, but it won't stop it. Once you have that though, fail2ban does do a nice job of making the perpetual brute force attacks significantly less obnoxious. I've seen machines effectively DDoSed by brute-force ssh attempts, either with the network overloaded or filling up disk with ssh's logs of the failed attempts. Not as bad as getting hacked, but still annoying. A serious botnet attack will be able to spread it over thousands of IP addresses, but IME, those are relatively rare. Most attacks are still coming from a handful of hosts at a time and fail2ban basically stops them dead in their tracks. The other useful thing to do with fail2ban is to use it along with a whitelisted range of networks. Even if you aren't on a private network, not every server needs ssh open to the entire world. You can often get away with whitelisting the local network and maybe a few ISPs' ranges where admins are likely to access it from. I run fail2ban even on machines on private networks. If one of the other machines gets hacked, one of the first things they'll usually do is start trying to brute-force other machines on the network. Since it will probably only be a couple compromised machines, fail2ban is useful here. I find that it does also give me useful data as well. Eg, I have simple graphite metrics based on the number of bans/minute. If it gets unusually high, I can get an alert and perhaps notice that other hosts have been compromised, or do a quick firewall rule or two to drop packets from an entire network for a while.