On Fri, May 17, 2019 at 7:24 AM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Thu, May 16, 2019 at 2:54 PM Ben Cotton <bcotton(a)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: jjelen(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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