Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
> 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.

+1 to option 3 for interactive installs. I like option 1 a little...
but I don't think Anaconda should be in the business of messing with
default upstream OpenSSH settings any more than it needs to, and I
don't think it needs to here.

For the non-interactive case, cloud-init users can already create new
user accounts. Kickstart users can script new user creation or
sshd_config changes, as they would any other non-default change they
would prefer in their 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux