|Line 39:||Line 39:|
Revision as of 12:56, 13 January 2015
- 1 Set sshd(8) PermitRootLogin=without-password
Set sshd(8) PermitRootLogin=without-password
To restrict remote root login facility in sshd(8) by default.
- Targeted release: Fedora 22
- Last updated: 24 Nov 2014
- Tracker bug: <will be assigned by the Wrangler>
Sshd(8) daemon, by default, allows remote users to login as 'root' user. This provides remote attackers an option to brute force their way into a system and gain administrative access. 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|without-password' which controls sshd(8) behaviour; it is set to be 'Yes' by default.
Restricting remote root login by setting PermitRootLogin=without-password would help to harden Fedora systems, moving it an inch closer towards 'secure by default' future. This option would encourage people to move from password based authentication to ssh keys based authentication, which provides much better safety as compared to passwords. Password based authentication is susceptible to brute force attacks. Users can have non-root accounts with weak passwords too, yet restricting direct remote root login keeps an attacker a step away from getting full control on a system.
-> https://www.piratepad.ca/p/ssh-remoterootloigin -> https://lists.fedoraproject.org/pipermail/devel/2015-January/206157.html -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
- Local installations: wherein a user can navigate through the installation process as prompted by the Anaconda installer. The system being installed could be local or remote. The variant being installed could be either of server or workstation.
- Automated installation: wherein a user can not navigate through the installation process. The variant could be either of sever or workstation.
- Cloud installations: wherein cloud images are built with automation tools with predefined configurations. Mostly these don't have(or need) non-root user account.
The immediate effect of this change is that, users need to create at least one non-root user account, so that they are not locked out of their systems. Since the change proposes to restrict remote 'root' access to ssh keys based authentication, it is imperative that such keys are automatically generated for the 'root' account, either in '%post' install section, or via first-boot or cloud-init programs.
- If we restrict remote 'root' access, generation & export of ssh keys becomes imperative.
- Cloud-init tool seems to have facilities for that.
- Anaconda installer needs to mandate creation of non-root user account.
- Non-root user account could be used to export root's public key to allow remote 'root' access to a host.
- Omission of non-root user creation should show discretionary warning message about restricted remote 'root' access.
- Omission of such user account should prompt user if they wish to enable remote 'root' login, and set the parameter appropriately.
- Tools used to perform automated remote OS installations need to address the possible lock-down scenario due restricted remote 'root' access.
- Remote root access can be enabled in the '%post' install section of a kick-start file.
Benefit to Fedora
Fedora systems and in turn users benefit by being more secure and less vulnerable by default.
- 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.
If an old system did not have a non-root user account, disabling remote root login could practically lock users out. To avoid this from happening, we need to ensure that at least one non-root user account exists on a system that is known to all users.
How To Test
To test this feature try - $ ssh root@.... to a remote machine. It should fail with an error message like -> Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
Remote users would not be allowed to login using 'root' account. They would have to first connect using a non-root account and then upgrade their privileges via sudo(8) or su -.
Anaconda, GNOME, openssh-client and openssh-server could be affected by this change.
- Contingency mechanism: if the feature is not complete the deadline, sshd(8) would continue to allow 'root' login from a remote machine.
- Contingency deadline: Beta freeze
- Blocks release? No
- Blocks product? No
There is no documentation yet. The topic has been discussed here -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html