Add http://www.heiho.net/pam_shield/ and http://www.snafu.priv.at/mystuff/pam_recent.c to that list.

I use use some iptables voodoo with them to auto-whitelist on successful auth and blacklist on failed auth attempts.

Three things to note about google authenticator:

1. ssh keys bypass it unless you have a patched version of OpenSSH with multiauth

2. It can be configured to have you append your one time code to your password for interop with things that can't handle keyboard-interactive auth

3. It is self contained and doesn't use any google services to function.

With regard to #1, newer OpenSSH supports AuthenticationMethods, which lets you chain keys and PAM.

Ah, thanks. For a while you had to apply a patch to get that, I wasn't aware it'd be merged.

If you are in a real production environment you shouldn't be opening up SSH to the world, most people that are accessing SSH have enough know how tunnel through a VPN. So for most of my uses this is a non-issue.

fail2web for me is used on Asterisk servers to watch HTTP auth and SIP. Most of the customers I work with have very strict corporate IT policies, they have to review every piece of hardware and most of the time I can only get an ATA approved. So I drop an ATA on their network with SIP/TLS and ZRTP and they setup the client. However, I don't want to make the assumption that their network is 100% safe, so fail2ban serves me well here.

Also to your point of fail2ban being overloaded, this has never happened to me. I see scans/brute forces all the time add after five fails I usually block the small subnet, and the problem goes away.

All of the solutions you posted are 100% a no go for the problems I am trying to solve.

Yes, the reality is that "baseball" is a bad password, and ssh as root is a bad idea but getting auth.log spammed into oblivion is also a bummer. It feels like a web GUI would help less experienced sysadmins not just apt-get remove fail2ban when they get themselves locked out for the first time.

root is no worse from a security standpoint than any other user. If knowing your username helps somebody guess your password or bruteforce your key, the username isn't the problem.

Using multiple users is great from a compartmentalization / user_management standpoint, but it doesn't protect against brute-force.

I thought Fail2Ban hooked directly into iptables? How would you get locked out or overloaded?

I don't necessarily think Fail2Ban needed a GUI, but I guess I never thought it was a "bad" thing?

It uses iptables, but it detects things to block by reading log files, and it's not exactly efficient in doing so. As such, if an attacker can pump lines in (like by having their botnet SSH to your system), they can get it to spin a core.