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.
–
grieveMay 27 '09 at 20:59

@Roy I am talking about firewalls other than the ones I own. For example if I want to ssh into my home machine from Starbucks, their firewall blocks the outgoing port. I cannot change that. (I just used Starbucks as an example. I have no idea what ports they actually block or not).
–
grieveMar 6 '12 at 21:16

How many people or locations (with floating public IPs) do you really need accessing your public ssh connections ?

Depending on the number of public ssh hosts you are maintaining and whether you can narrow down your general connection criteria's then it may be a simpler, maintanable configuration to limit access to a few external hosts.

If this works for you, it can really simplify your administration overhead.

+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!
–
dwcMay 23 '09 at 17:44

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.
–
Joshua EnfieldJul 2 '10 at 19:51

1

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.
–
sherbangAug 25 '11 at 12:03

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.
–
paddyJan 6 '13 at 21:52

Use the "AllowUsers" option in sshd_config to ensure only a small set of users can log in at all. All others will get rejected, even if their username and password are correct.

You can even restrict users to logins from a particular host.

e.g.,

AllowUsers user1 user2@host.example.com

This will reduce the search-space and avoid those old users which have accidentally been left laying around or enabled (although these of course should be disabled anyway, this is an easy way to stop them being used for an SSH-based entry).

This doesn't entirely stop the brute-force attacks, but helps reduce the risk.

Since you're using FreeBSD, consider running the PF firewall and using its solid connection rate-limiting features. This will allow you to send the brute forcers to a black list if they connect on a frequent basis

If this box must be accessed from the outside world, consider using a PF rdr rule to not allow traffic to port 22, but to redirect some obscure port to it. Meaning, you have to connect to port 9122 instead of 22. It is obscure, but it keeps the knockers away

Further to sherbang's rate-limiting suggestion, the length of the delay is important. By increasing the delay between groups of 3 login attempts from 2 minutes to 20 minutes, the number of different IP addresses that made more than three attempts to login dropped, comparing two week-long periods on one machine of mine, from 44 attempts to 3. None of those three addresses kept trying for longer than 11 hours.

Very anecdotal, but auth.log became a whole lot more readable for me...

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"...
–
wombleMay 6 '09 at 0:07

install OSSEC. not only it monitors for repeated logins, it will enter a temporary block with iptables for the offending ip. And at the end it will send you a report stating the details. it logs everything, which is nice. Somone once tried over 8000 login names to log in with. i parsed the logs and got a nice user list out of deal ;)