On Fri, May 17, 2019 at 7:24 AM Stephen Gallagher <sgall...@redhat.com> wrote: > > On Thu, May 16, 2019 at 2:54 PM Ben Cotton <bcot...@redhat.com> 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: jje...@redhat.com > > > > == 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.
I usually ssh in and enroll my machines to my ipa server, I am not sure how we can do that in the arm cases where we use pre-generated images. I know I can use cockpit, however, the socket is generally disabled, and them seems to randomly get disabled post install. Dennis > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
