On Jul 28, 2015, at 5:17 PM, Chris Murphy lists@colorremedies.com wrote:
On Tue, Jul 28, 2015 at 4:34 PM, Warren Young wyml@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.