From Fedora Project Wiki
(Created page with " <!-- 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 --> =...")
 
m
Line 52: Line 52:
  
 
== How To Test ==
 
== 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).
+
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).'''
  
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
 
  
 
== User Experience ==
 
== 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 -'''.
+
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 ==
 
== Dependencies ==
Line 63: Line 62:
  
 
== Contingency Plan ==
 
== Contingency Plan ==
* Contingency mechanism: if the feature is not complete by default, it would continue to allow 'root' login from a remote machine.
+
* 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  
 
* Contingency deadline: Beta freeze  
 
* Blocks release? No
 
* Blocks release? No
Line 69: Line 68:
  
 
== Documentation ==
 
== Documentation ==
There is no documentation yet, but the topic has been discussed here -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
+
There is no documentation yet. The topic has been discussed here -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
  
 
== Release Notes ==
 
== Release Notes ==

Revision as of 09:51, 25 November 2014


Set sshd(8) PermitRootLogin=no

Summary

To disable 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 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

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