On Fri, May 17, 2019 at 8:24 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > 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: What would be the fail-safe setting if any? > 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. Which could be shown in a popup "Do you really want to do this?" window of sorts. > 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. Or pipe it using netcat/something. > 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. That seems similar to the approach adopted by ubuntu and it has worked. With that said, I do not see the difference between ssh'ing using an user in the wheel group vs root as both can do the same. But that is me. Being able to tell who sudo'ed, yes. > 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 _______________________________________________ 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
