There are a number of different packages out there to shut out IPs from which brute-force SSH attacks are launched on your system. For example:

What are the pros/cons of these, or any others?

My current solution is to take the email that logwatch generates every day and dump the egregious IP addresses into a text file which I feed into a script that then rebuilds iptables. It's hacky, time-consuming and manual, and I'd like a better way.

(Note that I didn't ask what was the "best" way to solve the problem, because there is no "best" way to do anything.)

3 Answers 3


Another one is fail2ban, which relies on iptables (so it works with any service, not just ssh). With fail2ban, you can:

  • Specify path to any log file (apache, ssh, nginx, mail server, ...).
  • Specify regex for attack patterns (e.g., more than 10 "404 errors" by the same ip on nginx access log in 6 seconds)
  • Specify regex to ignore certain patterns (very useful!)
  • Specify ban time
  • Send an email (or any other alert...)
  • Fully customizable (you can write your own alerts and filters)

One "disadvantage" of DenyHosts is that it requires tcp wrappers, so it will only work with services that look at the /etc/hosts.deny file. But to be fair with DenyHosts, sshd is compiled to use TCP Wrappers on most Linux distributions. I also find DenyHosts to be easier to configure out of the box than fail2ban (but less powerful).

Reference to a similar SF question

  • fail2ban, thankfully, also works with pf - not just iptables Commented Dec 14, 2013 at 22:45

I use DenyHosts, so I can at least answer for that:


  • It's completely automatic
  • It's configurable (how many failed attempts before blacklisting, for usernames that don't exist, usernames that do exist, and a special entry for root)
  • It can e-mail you with a list of newly blacklisted hosts periodically, and/or run a given program every time a new host is blacklisted
  • It supports automatically un-blacklisting hosts after a while


I don't have any irreparable cons, as long as you use it correctly:

  • In its default configuration it won't alert you to newly blacklisted hosts, so if somebody is attacking your network from hundreds of different addresses you might not notice right away like you would if you're monitoring your logs manually, but (as mentioned in the pros section) it can e-mail you or run an executable to alert you when new hosts are added
  • By default it will blacklist your hosts the same as any other, so you probably want to add them to /etc/hosts.allow. I locked myself out once just failing at typing my password, and once somebody from work tried to login to my root account as a joke and blacklisted my work IP, and it took me a few days to figure out why I suddenly couldn't connect to my network from work anymore

A simple and in practice effective protection against scan-based attacks is not to use the standard port. 443 (the https port) exposes you to different brute-force attacks that aren't going to crack your weak passwords, and possibly works through more firewalls than the default port (22).

Most methods to prevent ssh brute force attacks are great ways to self-DoS (oops, I screwed up the configuration! Oops, I did a bunch of quick rsync's and am now banned for the day!) or assisted-self-DoS (Oops, the attacker comes from/has subverted a machine in the same subnet as me (dynamic IP range, college network...) and I'm getting banned as well!).

If you only log in from a few places, you can just whitelist source IP addresses. That's obviously no good if you want to ssh from your laptop or cell phone on the go.

Having an ssh daemon that only listens to IPv6 connections should protect you from scans for a few years yet. But many firewalls won't let you transport IPv6 in any reasonable way.

Another method you don't mention is port knocking. It doesn't suffer from as self-DoS problems (other than misconfiguration), but it doesn't cross firewalls well, and can add several seconds' latency to connection establishment.

If you have good passwords, or you can live without password authentication, disable password authentication. (Keys and one-time passwords are sufficient for most use cases: if you don't trust the client machine enough to store an ssh key, you don't trust it not to have a keylogger either). Then brute force attacks will cost you a bit of CPU and bandwidth but don't expose you to an intrusion (as long as you've checked none of your keys came from a Debian low-entropy OpenSSL).

All in all, do note that changing the port does not significantly reduce your exposure. You'll get less scanning, but all you can cut off is the low-hanging fruit that seeks to exploit old vulnerabilities and weak passwords. As long as you keep your daemon up to date and either enforce reasonable passwords or and reasonable attempt rate limits, switching the port is more of a liability than a security measure.

  • 2
    I agree that it takes some practice to not ban yourself ;-) Changing default ports and not relying on a password but on a password-protected key are also good advice. But I really don't know why I should let bot networks fill my access log files while my ssh and web server have to deny thousands of requests per hour. With fail2ban, my access log is clean and my server applications do not see this traffic at all (except the first X bad requests :-) ).
    – Barthelemy
    Commented Oct 12, 2010 at 20:05
  • Using a nonstandard port doesn't add much protection at all. Scanning for SSH on a nonstandard port takes only a few minutes more then scanning for SSH on port 22 (Assuming that the cracker does a scan and the scan was not blocked by an IDS. But if you have an IDS, then port obfuscation probably unnecessary). If I was a cracker and I found SSH on a non-standard port, I would be even MORE interested because I know the admin thought this service was precious enough to hide, and is relying on security by obscurity. Commented Oct 12, 2010 at 20:45
  • 1
    @Stefan: Most attacks are not against a given host but against a given service. For that it's much more effective to scan a single port on many addresses than many ports on each address. And if you actually have an attacker targetting you, you'd better know, so you'll want strong or forbidden passwords and the attacks to be logged. Commented Oct 12, 2010 at 20:56
  • 1
    @Stefan I see nonstandard ports as an effective solution to a nuisance (brute-force scans) and not really as a security measure (i.e., preventing someone from taking control of my server).
    – Barthelemy
    Commented Oct 12, 2010 at 21:35
  • 1
    @sudowned Specifying a different port is hardly a nuisance. It's just one line in .ssh/config. Lockout is a problem if the firewall won't let you through, and the easiest solution is to stick to port 22 and also listen on 443. I do agree that switching the port doesn't really improve security, maybe I should make that clearer. I don't know why you consider it impossible for an SSH daemon not to support password authentication: it's only a matter of adding a line to sshd_config with OpenSSH, the most common implementation. Commented Apr 29, 2013 at 9:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .