Key takeaway:<p>> And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night.<p>Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers.<p>Other than that, the main gist of this post is: on most platforms, the default settings for remote login already make brute-force login attempts annoying at best, and with fail2ban or something similar, it's a non-issue.
This really is a bug in <i>how</i> OpenSSH USE_PAM is implemented.<p>Particularly if you presume that PAM is the devil, the last thing you want to do, from a security standpoint, is to let a client dictate how a server applies PAM. The policy _has_ to be entirely controlled by the server's config. Once you let the client decide, you're just asking for things to go wrong.
Thankfully my use of PAM is for 2FA with SSH when I don't have my key. So they wouldn't have been successful in pulling off a bruteforce anyway. But it's annoying that their attempts weren't being limited as it can waste resources...
I have disabled PAM by default on all my boxes that run sshd for the last 9 years out of habit, I long ago forgot the reason why (probably because the gentoo sshd handbook entry said it was a good idea). Why UsePAM is set to yes in sshd_config by default on many distros is beyond me.
NetBSD is integrating a system called blacklistd to address fail2ban being less than elegant.<p><a href="http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-current" rel="nofollow">http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-curr...</a>
I am curious as to what happens when this is done with an existent user? I feel like there would be different behaviors for timeouts when a non-existent username is used and when a wrong password is used for an existent username.
They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln?<p>This is a serious vuln for FreeBSD. Period.
FreeBSD hasn't released a patch, so I patched it myself.<p><a href="https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-cve-2015-5600-on-freebsd/" rel="nofollow">https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-cv...</a>