On Jul 28, 2015, at 5:17 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jul 28, 2015 at 4:34 PM, Warren Young <wyml@xxxxxxxxxxx> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
