On Jul 28, 2015, at 2:27 PM, Chris Murphy <lists at colorremedies.com> wrote: > > On Tue, Jul 28, 2015 at 11:27 AM, Warren Young <wyml at etr-usa.com> wrote: > >> Your freedom to use any password you like stops at the point where exercising that freedom creates a risk to other people’s machines. > > Your freedom to have sshd enabled by default stops at the point where > exercising that freedom creates risk to other people's machines. You’re offering a false choice. We do not have to choose between cutting the tree down or leaving the fruit to rot on the twig. Fedora is rightly choosing to pick this low-hanging fruit. If you want a Linux distro that doesn’t ship with sshd enabled by default, that is already available. Given that CentOS does ship with sshd enabled by default, it makes sense that it should not allow itself to be so badly misconfigured that it allows trivial exploits. > I can also use that logic with, password based auth by default, rather > than PKA by default. That’s more low-hanging fruit; we might get there someday. They turned off "PermitRootLogin yes" and "Protocol 1" in EL6 or EL7, the previous low-hanging fruit. Do you think those were bad decisions, too? > A rather strong argument can be made, much more so than a very weak > > weak password quality policy, for sshd on a default 7 day disable > timer. That is, by default, after 7 days, sshd is stopped and > disabled. The stock PAM on-fail delay is about 2 seconds. I can’t see that sshd has any rate-limiting built into it, but it does limit the number of unauthenticated connections to 100 by default in EL7. Together, this means a small botnet could try 50 guesses at a single account’s password per second. The current non-policy allows abc1 as a password. According to: https://www.grc.com/haystack.htm …that password can be brute-forced in about half an hour at 1000 guesses per second, or 4 days at 50/sec. Your 7-day window is too short, if you don’t institute *some* kind of password quality minima. Also keep in mind that the GRC calculator is assuming you’re brute-forcing it, and not intelligently trying common passwords first, and sensible variations. The stock rules currently allow “monkey” as a password, which the GRC calculator considers stronger than “abc1” due to the length, but it’s a top-10 most-used password, so it will be among the first to be tried by any intelligent attacker. > I think we'll see either sshd disabled by default That wouldn’t break my heart, either. > or PKA required by default The main problem with that is that you need some way to install the client computer’s public key into the authorized_keys file during initial setup. You don’t need password auth to be enabled to do that, but it would make things considerably more difficult. Meanwhile, *this* thread is about using 9+ character passwords that aren’t laughably easy to break, which is not difficult. > And yet the weak password policy is too strong for many > legitimate use cases where the use case/environment aren't high risk > for such passwords. Really? Which of these new rules is onerous? http://manpages.ubuntu.com/manpages/trusty/man8/pam_pwquality.8.html