Stopping SSH Brute Force Attacks resulted in some really great comments and suggestions from readers.
So, this is a follow up to the last SSH brute force post. I didn’t realize there was such a wide selection of applications for dealing with this, but there is! The two best looking options in my opinion are Fail2ban and DenyHosts.
I’ve actually started using DenyHosts on two machines now, and it’s working very well. I chose to go with DenyHosts for a very simple reason. Community stats. I love stats.
Anyway, if you’re looking for something to protect against ssh brute force attacks, go with Fail2ban or DenyHosts, they’re still being actively developed. I can’t say the same for Breakinguard, as it appears to have been abandoned about 1 year ago. And like I said, DenyHosts does it’s job extremely well, I couldn’t ask for anything more.
If you’re looking for another solution, try using cryptographic keys instead of passwords. A tutorial on configuring SSH to look for keys instead of passwords can be found here. This was suggested by commenter pwyll.
Oh, and this is the 700th post. yay!
Popularity: 7% [?]
I’ve used DenyHost with great success when we suspect SSH brute-force attacks on servers where we’ve little control over user behavior (such as web hosting systems).
But I cannot stress enough how limiting access initially and adjusting SSH variables is the best method of security.
MaxAuthAttempts, AllowUsers and similar variables can be added to ssh’s configuration to reduce the likelihood of a brute force attack being successful.
Also, forcing users to use 8 character passwords is very helpful, and of course using only keys to access root.