Preventing brute force attacks against ssh?

security ssh brute-force-attacks

9,939

Solution 1

Here's a good post on that subject by Rainer Wichmann.

It explains pros and cons on theses methods to do it :

Strong passwords
RSA authentication
Using 'iptables' to block the attack
Using the sshd log to block attacks
Using tcp_wrappers to block attacks
Port knocking

Solution 2

I use fail2ban which will lock an IP out after several failed attempts for a configurable amount of time.

Combine this with password strength testing (using john (John the Ripper)) to ensure brute-force attacks will not succeed.

Solution 3

Ons small thing you can do is use something like DenyHosts:

http://denyhosts.sourceforge.net/

It uses the built-in hosts.allow/hosts.deny to block out SSH abusers.

Solution 4

Change the port used (as Trent mentioned)
Require encryption keys instead of passwords. http://novosial.org/openssh/publickey-auth/
Blacklist attacker ips
Whitelist known users to prevent accidental blacklisting. (as Samiuela mentioned)

Solution 5

One of the easiest ways to avoid these attacks is to change the port that sshd listens on

View more solutions

9,939

grieve

Something clever

Updated on September 17, 2022

Comments

grieve almost 2 years

What tool or technique do you use to prevent brute force attacks against your ssh port. I noticed in my Security logs, that I have millions of attempts to login as various users through ssh.

This is on a FreeBSD box, but I imagine it would be applicable anywhere.
phirschybar about 15 years

I have tried this and users find it annoying. If it's only one or two people, this could be a good option, and would nearly eliminate brute-force attacks
C. Ross about 15 years

If, of course, you system can stand it.
Chris Ballance about 15 years

Security through obscurity, effective every single time.
Ryaner about 15 years

Whitelisting is hugely important if you are doing any kind of blacklisting unless you want to get locked out.
Chris Ballance about 15 years

-1 Ever heard of DoS attacks?
Dave Cheney about 15 years

Fail2ban is excellent. It was simple to extend it to monitor /var/log/maillog and get it to ban persistent spammers from hitting my mail server
womble about 15 years

Yeah, because SSH is the only service susceptible to brute force attacks. If you've got a port open to the Internet, it can be used to hammer your machine into oblivion. You probably put your HTTP server on weird ports too, and behind port knocking, to "avoid DoS attacks"...
dwc about 15 years

+1 for having the absolute best answer. Those two things are the only reasonable steps, and they are very effective indeed. Either alone is worthwhile, and both together more so. Boo on the other answers advocating security through obscurity!
grieve about 15 years

I wouldn't mind changing the port all that much, but I have learned that most firewalls (other than my own) tend to lock down all ports other than the common ones (80,22, 443, etc). If I am behind those firewalls I cannot get to my home server on that nonstandard port. For me that is a no go.
Araejay almost 15 years

@grieve then change our firewall to let that port out?
user2910702 almost 14 years

Fail2ban can be combined with an iptables chain that sends tcp traffic to the TARPIT target, if you are feeling nasty (from xtables-addons).
Joshua Enfield almost 14 years

I might be misunderstanding something, but many mainstream browsers connect between 4-6 connections at a time - even though the HTTP standard sets it at 2.
sherbang almost 13 years

Yes, that would be a problem if you were trying to rate-limit port 80. You're not connecting to ssh with your web-browser, and ssh sessions are long-lived sessions that maintain state, not short-lived stateless sessions like http. Parallelizing ssh sessions like that doesn't make sense. That's not to say that there isn't some niche use of ssh that this would break, but it's rare.
paddy over 11 years

This solution is not so good if, like me, you are serving Subversion via ssh. A single SVN query can make a great number of connections in quick succession. If providing that service, you could either use a second sshd service on another port, or whitelist known IPs. I am thinking of using fail2ban or sshdfilter to catch obvious attacks the first time around, without punishing my legitimate users.
ZEE about 6 years

good to know this option too...