From Fedora Project Wiki
(Change Proposal ready for 2015-01-14 FESCo meeting (#1386))
m
Line 2: Line 2:
 
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
 
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
  
= Set sshd(8) PermitRootLogin=no <!-- The name of your change proposal --> =
+
= Set sshd(8) PermitRootLogin=without-password <!-- The name of your change proposal --> =
  
 
== Summary ==
 
== Summary ==
To disable remote root login facility in sshd(8) by default.
+
To restrict remote root login facility in sshd(8) by default.
  
 
== Owner ==
 
== Owner ==
Line 33: Line 33:
  
 
== Detailed Description ==
 
== 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.
+
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.
  
Please see -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
+
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.
 +
 
 +
Please see:
 +
  -> https://www.piratepad.ca/p/ssh-remoterootloigin
 +
  -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
 +
 
 +
== Major use-cases: ==
 +
 
 +
* '''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.
 +
 
 +
=== Workflow changes ===
 +
 
 +
* '''PermitRootLogin=without-password'''
 +
** 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.
 +
    See -> https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==

Revision as of 12:53, 13 January 2015


Set sshd(8) PermitRootLogin=without-password

Summary

To restrict remote root login facility in sshd(8) by default.

Owner

  • Name: P J P | FST
  • Email: <pjp@fedoraproject.org>
  • Release notes owner:

Current status

  • Targeted release: Fedora 22
  • Last updated: 24 Nov 2014
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

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.

Please see:

 -> https://www.piratepad.ca/p/ssh-remoterootloigin
 -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html

Major use-cases:

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

Workflow changes

  • PermitRootLogin=without-password
    • 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.
   See -> https://lists.fedoraproject.org/pipermail/security/2014-December/002061.html

Benefit to Fedora

Fedora systems and in turn users benefit by being more secure and less vulnerable by default.

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.

Upgrade/compatibility impact

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


User Experience

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

Dependencies

Anaconda, GNOME, openssh-client and openssh-server could be affected by this change.

Contingency Plan

  • 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

Documentation

There is no documentation yet. The topic has been discussed here -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html

Release Notes