On Jul 28, 2015, at 5:17 PM, Chris Murphy <lists at colorremedies.com> wrote: > > On Tue, Jul 28, 2015 at 4:34 PM, Warren Young <wyml at etr-usa.com> wrote: >> But as I have repeatedly pointed out here, the stock rules really are not that onerous. They basically encode best practices established 20 years ago. > > In order to protect a system that's Internet facing with > challengeresponseauth (rather than PKA) In the context of SSH, challenge/response authentication generally means things like OTP fobs and smart cards. It is not a synonym for password auth, it is an alternative to it. Some definitions of C/R do include password auth under the same umbrella, but SSH uses the term in a more narrow sense, where it means any system where the actual credentials do not cross the wire, only a trapdoor response from which you cannot reverse-engineer the credentials. In that sense, PKA is also a form of C/R auth, though the OpenSSH docs don’t use the term that way. > the minimum password quality > would need to be at least initially onerous. Not true. CentOS 7 limits SSH password guesses to about 50 per second, and then only if you can rope 100 attackers together to go after a single account. A random 9-character password will withstand about a million years of such pounding. You only need to go beyond that when you’re trying to fend off offline attacks, such as clusters of GPU number crunchers tearing through /etc/shadow. > Whereas if things are properly configured such that ssh is only used internally I don’t have the luxury of setting such a boundary. I must access remote systems via SSH all the time to do my job. If your alternative is a VPN, all you’ve done is shift the burden, since that is equivalent to PSK and strong passwords in SSH. In fact, properly configured, SSH is a form of VPN.