Brute-Force SSH Server Attacks Surge (InformationWeek)

4 billion ip address, biggest botnets are of the order of 1 million machines. the default on
denyhosts is something like 10 fails per IP address.

there are 26^5 = 11 million, 5 character lowercase passwords

there are 26^7 = 8 billion, 7 character lowercase passwords

Ubuntu does not install an ssh server by default. which consumer distros do?

Ubuntu also, by default does not have a root user, so if you want to brute force you have to
guess a username as well.

crazy idea:
what if, once in 10 times, when an ssh login failed, the ssh server pretended that it has
succeeded, and gave a pretend shell that did nothing. would that confuse the crackers?

Yes they have been doing this for a while.. The latest set of attacks are using it more. I
have seen attacks where machine A goes for account "foo, foo1, foo2" and then machine B does
"foo3, foo4, foo5" and then machine C goes for "foo6, goo, goo1" and machine A tries again
(well its a lot bigger than that but just logging in once and coming back an hour later is
enough to get past most public ssh servers fail2ban systems.) Add onto that a lot of users
think Q1w2e3r4 is a good password and are sure to get some account on a university or big ISP
sometime.

While I agree with your general point, I have two points of 
partial-contention.

Most importantly, if you allow password authentication at all, you need to 
pay attention to failed logins, and take steps to prevent someone from 
eventually getting around to guessing your good password.  (I watch my 
logs and manually block IP addresses that are trying to brute-force their 
way in, but I'm lucky enough not to be getting hit nearly as hard as 
others are.)

Also, I've long disliked fail2ban and similar tools because it's too easy 
for legitimate users to get blocked.  But some variant might be 
appropriate, such as one that notifies the sysadmin and asks for approval 
before blocking.  (Though of course this adds more of the evil complexity 
that you rightly argue against.)

I've toyed with the idea of a system that not just penalizes failed 
logins, but also gives positive points for successful logins, so that it's 
harder for legitimate users to get blocked.  And of course, if blocking 
does happen, it should eventually expire.

I use fail2ban with a whitelist on port 22 and port knocking on two additional ports (with a
five port knock for each).

Thus I can be assured that I can still get in even if someone has spoofed failures from some
adress I'm using that's not on my whitelist.

I could just turn off port 22 on that server since I only ever use one of the alternatives.

The advantage of fail2ban or its ilk in this case is to prevent the bandwidth and CPU hit for
repeated brute force ssh attempts.  hiding the alternatives behind a knock sequence is even
more effective since the casual port scanners can't even find the running service.  If I see
brutish failures on one of the alternative ports then I can be certain that someone sniffed my
knock sequnce ... and change it.