Brute-Force SSH Server Attacks Surge (InformationWeek)

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.