On Thu, May 16, 2019 at 2:54 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd > > == Summary == > The upstream OpenSSH disabled password logins for root back in 2015. > The Fedora should follow to keep security expectation and avoid users > surprises with this configuration. > > == Owner == > * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer > * Email: jjelen@xxxxxxxxxx > > == Detailed Description == > > The OpenSSH server configuration contains a configuration option > `PermitRootLogin`, which controls whether the root user is allowed to > login using passwords or using public key authentication. The root > login is target of most of the random or targeted attack on Linux > systems and password is usually the weakest part. For that reason, the > upstream OpenSSH changed this option in 2015 to `prohibit-password`, > which still allows public-key authentication, but prevents the > password logins. Fedora was for many practical reasons keeping the old > configuration since then, but the difference is no longer bearable and > might confuse users expecting the root logins will not be enabled out > of the box. > > On the other hand, there is still a lot of infrastructure, installers > and test instances that simply might depend on this configuration and > therefore this change needs to go through the system-wide change so > everyone is onboard. > > == Benefit to Fedora == > > This will provide more secure Fedora installations out of the box and > prevent inadvertently accessible root logins in the wild. > I'm not particularly *opposed* to this change in behavior, but in the Fedora Server case, SSH is the primary mechanism for gaining access to the system. If we disallow password logins for root, then many installs will be inaccessible and users will get... grumpy. There aren't really any major problems for interactive installs where the user has direct console access, so I'll disregard that case for the moment. For kickstart-based installs, I suppose users would normally know to put their SSH public keys in place, so that's also less of a concern. The problematic case I see is the remote VNC headless install. The installation is interactive, but there may not be a way to gain direct access to the installed system after that. We need to ensure that the resulting system is always accessible. Right now, the interactive installer would allow us (even encourage us) to set up that machine with only a root user and password, which after this Change would mean that the system is not reachable. I see some possible options here, all requiring Anaconda changes: 1) Provide a checkbox in the root user creation spoke (defaulting to "off") to enable root password logins over SSH. Ideally with notes about why it's recommended not to do this. 2) Allow users to provide a public SSH key for the root user. Since this is generally not performed in an environment where the keys can be copy-pasted, we'd probably need to allow specifying a [tiny]URL for an authorized_keys file. 3) Force Anaconda to require the creation of a non-root user that is a member of the `wheel` group, so that this user can be used to SSH in and administer the system. Essentially, remove the root user creation spoke as an option from the interactive install. 4) Force Cockpit to be installed and available on any system that doesn't select a non-root user at installation time. This will allow a password-based login and allows the root user to set up their SSH keys via the "Accounts" tab. I'm all for hearing what other options we may have here, but those are the simplest ones I can think of. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
