F22 System Wide Change: Set sshd(8) PermitRootLogin=no

Stephen Gallagher sgallagh at redhat.com
Thu Jan 8 13:43:48 UTC 2015




On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
> 
> Change owner(s): P J P <pjp at fedoraproject.org> and Fedora Security Team
> 
> To disable remote root login facility in sshd(8) by default. 
> 
> == Detailed Description ==
> Sshd(8) daemon allows remote users to login as 'root' by default. This 
> provides remote attackers an option to brute force their way into a system. 
> Empirically it is observed that many users use their systems via 'root' login, 
> without creating non-root user and often have weak passwords for this mighty 
> account. sshd_config(5) has an option 'PermitRootLogin=yes|no' which controls 
> sshd(8) behaviour; it is set to be 'Yes' by default. Disabling remote root 
> login by setting PermitRootLogin=no would help to harden Fedora systems, 
> moving it an inch closer towards 'secure by default' future. Users can have 
> non-root accounts with weak passwords too, yet disabling remote root login 
> keeps an attacker a step away from getting full control on a system. There is 
> another option of disabling user login via password and require usage of 
> cryptographic keys for the same. But that could a next step in future.
> 
> Please see -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html 
> 
> == Scope ==
> * Proposal owners: to communicate with the Fedora maintainers of packages: 
> Anaconda, OpenSSH, GNOME, etc.
> * Other developers: packages like Anaconda, GNOME etc. need to update their 
> workflow to enable compulsory non-root user account creation and ensure good 
> password strength for it.
> * Release engineering: installer needs to ensure creation of non-root user 
> account with strong password. Similarly, all Fedora images must be created 
> with a non-root user account.
> * Policies and guidelines: unknown yet.


Can we clarify something here? Is this a request to change the defaults
globally for all Products/nonproduct installs?

I would argue that it could be sensible to do this for Workstation and
non-product installs, but not for Server and Cloud.

In the Server case, nearly every deployment is headless. Disabling root
login to ssh by default would mean that many people would have no way to
get into the system at all. (Yes, we could force the creation of a
non-root user at install time, but this user would by necessity be an
administrator capable of becoming root via sudo, so the distinction
is... fuzzy). The only other approach I could see for the headless
servers would be mandating the enrollment in an identity domain at
installation time (such as to FreeIPA or Active Directory).

Neither of those approaches is anything like ideal, so I would argue
that Server should continue to operate with the SSH root login being
available by default, but perhaps add documentation to the install guide
recommending to disable it if other accounts are available; perhaps even
by adding a simple kickstart directive (but no UI element) to accomplish
this.

We can also consider opening an RFE against realmd, so that if the
machine becomes enrolled in a domain, it disables the remote root login
by default. I'm not sure about that, however.


In the case of Cloud, I think the point is basically moot, since
cloud-init should be handling all the relevant setup for this in any
case.


tl;dr:
Let's make this change happen with a per-product config default, with
Workstation and Non-product setups disabling root SSH login by default.
Server should leave SSH login enabled (arguably conditional on whether
or not the user enrolls in a domain).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150108/9ac6618e/attachment.sig>


More information about the devel mailing list