On Wed, 14 Jan 2015 05:53:23 +0000 (UTC) P J P <pj.pandit@xxxxxxxxxxx> wrote: > Hello Simo, > > > On Wednesday, 14 January 2015 2:29 AM, Simo Sorce wrote: > > Sorry this is false. You got enough emails telling you this > > change is undesirable, that's the definition of opposition > > and means you have no _consensus_. > > > IIUC, that was for disabling remote root access completely with > 'PermitRootLogin=no'. As the 'PermitRootLoing=without-password' > option seems more preferred. As for the emails, many folks have also > said that it is a useful change. Ok, I state my opposition to without-password too inequivocably here. Mostly because it is just the same as 'no', given there is no way, in a regular install to seed a key into the root account. > IMO, the ones opposing are those who fear their current > setups/practices would break. Because they need remote 'root' access > in their set-up. Which is a genuine use-case. And to support it, we > could provide an option to enable remote root access with > 'PermitRootLogin=Yes', based on the the user's response to Anaconda > at install time, as was suggested in previous email. However, let's > not assume _all_ Fedora users have this use-case. Workstation do not even enable sshd (IIRC) so this impacts the server images (cloud images already do their magic with sshd so I am not counting them here), and server has different use cases and security implications than a generic population. > - IMHO, the change helps to harden Fedora systems and raise the > security bar a notch higher. It is similar to how we run services as > non-root user instead of 'root' user. I disagree that there is any similarity, and it doesn't bring security up a notch, most ssh attempts already probe for multiple users, preventing just root+password login is just cosmetics if user+password+sudo can do the same operations when broken in. If you want to do something effective against password guessing attack there are a few much better (and easy to implement) methods: 1) require a longer root password, so that brute forcing just fail 2) implement throttling so that trying to log in as root is slowed down considerably (and the related brute-force) 3) implement temporary black-listing, so that an IP that fails a pre-set number of times simply gets black-list for a pre-set period of time. > - The proposed change of using ssh keys for remote 'root' access > introduces that mechanism to a wider audience, which in turn would > help increase its usage in the future. Hence bring more value in the > long term. Except you have no mechanism to inject a key at installation time, you would have to implement that first, *then* you can think of changing the default. > - IMO, it is beneficial to supply hardened default configurations, > because they protect maximum users and have greater impact, than > otherwise. Security is not a feature, it must be available by default. Security and Usability are always at odds, exceeding in one and destroying the other is always as bad. The solution you propose only minimally affect security, the security increase is really negligible. But the usability is affected greatly, I think disproportionally, which is why I am opposed to this change. I am not against hardening, but this is just make things diofficult for little to no gain. > - Of course that does not mean we overlook the usability aspect. As > said before intention is _not_ to trouble users, but increase their > safety as much as we can. The intention may be not, then I'll call it poor execution/planning and still oppose this move *at this time* unless there is proof we address the usability problem first. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
