Bug 89216 (DisallowRoot) - RFE: disallow root login via password using SSH
Summary: RFE: disallow root login via password using SSH
Alias: DisallowRoot
Product: Fedora
Classification: Fedora
Component: openssh
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact:
Whiteboard: RejectedBlocker
: 97070 171595 450513 467604 498628 817325 1425285 (view as bug list)
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
Reported: 2003-04-21 10:58 UTC by Peter van Egdom
Modified: 2019-06-28 12:33 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2019-06-28 12:33:43 UTC
Type: ---

Attachments (Terms of Use)

Description Peter van Egdom 2003-04-21 10:58:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:

Red Hat ships a SSH configuration where the root user is allowed to directly
login using SSH.

For the sake of security it would be better to disable this functionality. If
necessary, a normal user can always become root by using su, and having two
logins decreases the chance of letting a cracker become root.

The following lines in the file "/etc/ssh/sshd_config" should be changed :

< #PermitRootLogin yes
> PermitRootLogin no

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. "# ssh" ( is running RH Linux 9)
2. <entering root password>

Actual Results:  User root logged in on

Expected Results:  Root login using ssh should be disabled.

Additional info:

Red Hat Linux release 9 (Shrike)


Comment 1 Michael Lee Yohe 2003-04-21 14:22:17 UTC
I'm trying to understand the logic in this request.

If I allow my root password to become compromised, then my machine would be
automatically vulnerable to all kinds of nasty attacks.  The root password
should be the most advanced and complicated password one would ever hope to
create for a login to a machine (usually, system administrators would hope that
all their users would treat their account and password with a little more dignity).

If there is one thing about the root password - is that is should be considered
the Holy Grail and not available to public consumption.  If no one knows the
root password, how could they possibly compromise the machine by attempting to
login as root via ssh?  Since ssh does not exchange nor pass your password or
authentication keys as plain text, what compromise is there?

Comment 2 Peter van Egdom 2003-04-21 15:18:07 UTC
I agree with you that a root password should be uncrackable; should consist of a
mixture of upper- and lowercase characters, numbers, special characters and only
be known to the system administrator of the machine.

But the reality is different.

There are a lot of curious home-users with Cable-modem or ADSL installing Red
Hat Linux and SSH is enabled by default on Red Hat Linux and I'm sure that there
are some people between these thousands of users with a password that can be
guessed by somebody else.

Comment 3 Michael Lee Yohe 2003-04-21 16:16:03 UTC
I don't think Red Hat should feel responsibility for "TPEBTCATK" (the problem
exists between the chair and the keyboard).  Since this is an RFE...

Component == Anaconda
Severity  == enhancement

Upon initial installation of Red Hat Linux 9.x (10 .. N), Anaconda should prompt
the user to enter the root password.  A dialog box could pop up informing the
user that if the root password were too easy to guess, the machine could be
compromised from external attacks.  The dialog box would ask if the user wished
to allow logins from root only at the console _or_ from the console and secure

Disabling root logins from secure shell by default is a bad idea to the
under-informed (remember the /etc/securetty debacle - "I can't login to my
machine via telnet.").

Comment 4 Aaron Sherman 2003-09-23 20:45:15 UTC
Just to put in my $0.02USD: The problem is that everyone "knows" that there is a
root account and that by default it can log in. This leaves the system (which by
default never disables an account for failed login attempts) vulnerable to an
admittedly slow brute-force attempt against a known account.

I would instead suggesst that the default configuration for Red Hat Linux be a
disabled root login. As for AS, I'm not sure. That brings up the question of the
wisdom of disabling root logins on a box that will most likely be in a
lights-out environment. I can't count the number of times that I have had to log
in as root due to NFS or load problems that rendered all other users (at least
nearly) impossible to log in as... then again one hopes that in such
environments you have some sort of console (serial or otherwise) access.

I'll let other debate the trade-offs there, but I think for RHL it's a pretty
clear choice.

Comment 5 David J Craigon 2004-01-22 15:46:28 UTC
Telnet servers by default do not allow root login (including the
RedHat configuration). Traditionally the reasons for this have been
(as I recall):

1) It makes it twice as many passwords to break
2) Who becomes root (using su) is logged. So you can find out which
user account was broken into first (and torture them :) ).

I think it should at least be consistent between telnet and SSH. As
someone who is a PEBKAC from time to time myself, I'm glad RH is
shipped as secure as possible. 

Comment 6 Travis Waldher 2004-09-01 19:10:58 UTC

As far as #2 goes, if I were a hacker and obtained the root password 
to your box, I would certainly modify, if no delete the log files 
behind me showing how I got in.  ;)

As far as root access on SSH.  Toss up, it's disable-able, but it's 
also a nice feature to have when the console is a ways away and 
something goes wrong in a NIS'd environment and there is NO local 
true-user account on the machines, nor would there ever be.

Since SSH is encrypted, unlike telnet which is cleartext, I would 
consider the threat pretty low.

Comment 7 Matthew S. Hallacy 2004-12-21 14:10:10 UTC
I agree that this is security through obscurity. There is no real
security benefit from disabling this option, and will only lead to
people complaining that it's been changed.

Comment 8 Tomas Mraz 2005-05-26 19:16:20 UTC
There is only within a hair of more security if you use arbitrary user account
and su with the root ssh login disabled so that the attacker has to find not
only password but the user name too. But this is completely equivalent to using
such password as you normally would and prefixing it by the user name you would use.
Because it's easily possible to modify the default if the administrator wants to
there is no reason for complicating things to administrator who knows how to
create a secure password.

We also support headless installs and the user accounts are added after reboot
on firstboot - too late for headless if you don't use kickstart.

Comment 9 Tomas Mraz 2005-10-24 07:39:50 UTC
*** Bug 97070 has been marked as a duplicate of this bug. ***

Comment 10 Tomas Mraz 2005-10-24 07:44:10 UTC
*** Bug 171595 has been marked as a duplicate of this bug. ***

Comment 11 Chris Nystrom 2005-10-24 08:40:47 UTC
I agree that the root password needs to be protected. What some commentors are
missing is that this is a way to help protect the root password. Comment #4 is
key. Everyone knows there is a privledged account named root. If it is not
directly accessible crackers will need to guess an unprivledged account name and
password, and then still break root while logged in to the local machine. It
seems to me that is a considerably more difficult task than a single password
that can be attacked remotely. So, I disagree strongly that there is no increase
in security.

Further, this is apparently a known exploit. I am seeing many dictionary
attempts from all over the globe on the root account on my systems. Since there
is nothing special about my systems (there are only a couple of home PCs), I
assume this is a widespread phenomena.

In my opinion it would be better to have a secure system, that I can easily open
up if I want to, than an insecure system that I have to figure out how to clean
up after a compromise.

I also note the Solaris ships with remote root ssh access disabled.

Comment 12 Matthew Miller 2006-08-21 15:18:35 UTC
Reopening as per discussion on fedora-devel, and tweaking slightly to reflect
suggested change: instead of disabling root logins entirely, instead use


which would allow logins via cryptographic key but not using password
authentication. That way, root ssh can easily be used for emergency
administrative access, but not present a vulnerability to random
dictionary-attack probing.

Comment 13 Tomas Mraz 2006-08-21 21:24:20 UTC
Without a good solution for the remote vnc install without a kickstart I don't
think we should change this default.

However I think that there could be an improvement to the standard use case of a
desktop install. The firewall is setup by default and has sshd port open - this
is necessary when firstboot is not run yet - but in case it is run the sshd port
should be closed by default. So s-c-securitylevel should be changed so it shows
and sets sshd port blocked by default when it is run in firstboot. This way an
user with a potentially weak root (and user) password doesn't have to
explicitely uncheck the sshd in s-c-securitylevel and his machine is protected
after firstboot. If the user explicitely opens the sshd port in firewall we can
expect that he is aware of potential attack on weak passwords through sshd and
has reasonably good root and user's passwords.

Comment 14 Kurt Erickson 2007-09-29 04:53:45 UTC
I hope you will reconsider leaving the root account exposed via sshd.

What is important to realize is that people who run Fedora as a desktop system
are asked for their root password multiple times on a daily basis, for
administrative reasons. This encourages people to choose easy to remember, easy
to type root passwords. These types of passwords are esp. vulnerable to
dictionary attacks.

The firewall is not an acceptable solution, as many reasonable people won't
think to check!

Users should either be informed that their administrative password is open to
dictionary attacks, and should be reconsidered in that light (possibly in the
firewall application?), or root login should be disabled by default.

As you know, bot nets and brute force password guessing are very real dangers.
Is it unreasonable to expect experienced users who need the feature to enable
it, and take the more secure route by default?

Comment 15 Tomas Mraz 2008-06-09 11:47:27 UTC
*** Bug 450513 has been marked as a duplicate of this bug. ***

Comment 16 John Poelstra 2008-07-02 19:23:48 UTC
It appears that discussion has ended.  Should this bug remain open?

Comment 17 Tomas Mraz 2008-07-02 19:33:11 UTC
It was kept open so there are no duplicate bug reports created.

Comment 18 Tomas Mraz 2008-10-19 16:00:17 UTC
*** Bug 467604 has been marked as a duplicate of this bug. ***

Comment 19 Fedora Admin XMLRPC Client 2009-03-10 09:20:37 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 20 Fedora Admin XMLRPC Client 2009-03-10 10:17:46 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 21 Fedora Admin XMLRPC Client 2009-03-10 10:19:42 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 22 Tomas Mraz 2009-05-04 07:22:49 UTC
*** Bug 498628 has been marked as a duplicate of this bug. ***

Comment 23 Scott Williams 2010-10-23 21:57:04 UTC
Perhaps a compromise may be, at firstboot:

chkconfig sshd off

Set PermitRootLogin no in /etc/ssh/sshd_config

For users that may actually use these features, it is dead simple for them to turn them back on.  And for the large amount of people who don't use ssh that have this vulnerability, this would be a much more secure setup.

It seems unconscionable to me to allow ssh root access via password with unlimited login attempts.

Comment 24 Fedora Admin XMLRPC Client 2011-11-30 12:25:25 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 25 Tomas Mraz 2012-04-30 06:40:54 UTC
*** Bug 817325 has been marked as a duplicate of this bug. ***

Comment 26 Jakub Jelen 2015-06-24 14:43:57 UTC
Few recent notes to keep track about this topic.

Upstream makes this default in future openssh-6.9:

Change Request on Fedora:
Discussion on mailing list:

Widely rejected so we will have to hold our old default with next update.

Comment 27 Fedora Admin XMLRPC Client 2016-01-08 13:42:54 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 28 Jakub Jelen 2017-02-21 08:32:40 UTC
*** Bug 1425285 has been marked as a duplicate of this bug. ***

Comment 29 Chris Murphy 2019-04-16 02:49:06 UTC
`PermitRootLogin no` was made the upstream default in 2015, and a subsequent change introduced `PermitRootLogin prohibit-password` which has been the default since there. There is zero good reason Fedora should be setting this to `yes` in 2019.

Also if Fedora is going to modify upstream configuration files, we need to point out at the top that we've modified it from upstream's defaults.

Right now Fedora, I argue inappropriately, suggests this file is the same as upstream by keeping the same header and not including a NOTE, for example:

#  NOTE: Fedora has modified the upstream version of this file:
#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $


Comment 30 Fedora Blocker Bugs Application 2019-04-16 02:58:29 UTC
Proposed as a Blocker for 30-final by Fedora user chrismurphy using the blocker tracking app because:

 Final release criterion:
*The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation). *

I've requested an assessment on impact from security@ but given that upstream openssh has set `#PermitRootLogin prohibit-password` for nearly four years, and Fedora is carrying a silent modification to allow root logins, I think it's at least an "important" impact.

Comment 31 Julen Landa Alustiza 2019-04-16 11:32:04 UTC
+1b +1 prohibit-password as default value.

Comment 32 Ben Cotton 2019-04-16 14:51:18 UTC
-1 blocker from me. This is a configuration setting, not a bug and thus can't violate the release criteria. I agree that the default should be changed, but this should be an F31 Change, not something we drop in via the blocker process two weeks before GA.

Comment 33 Adam Williamson 2019-04-16 14:53:16 UTC
-1 blocker. This is a policy question, and last time the change was proposed, it was rejected (see #c26 above); given that I don't think we can reasonably just use the blocker process to declare that it must be changed now, in a massive hurry.

Comment 34 Kevin Fenzi 2019-04-16 14:58:06 UTC
-1 blocker here for the reasons above (not a "bug", should go thru the change process, need to solve all the install methods that still need it).

Comment 35 Lukas Ruzicka 2019-04-17 10:59:32 UTC
-1 blocker, -1 fe. I agree with Adam that if we should want to make this change, it should be thoroughly discussed first! 
According to the bug number, this has been going on and on since 2003. We have existed all the time and probably have not experienced any massive break-ins, so I tend to believe that this change is nothing we could be spending our time too much though. There are other problems, we could be talking about.

Comment 36 Tomas Mraz 2019-04-17 11:19:07 UTC
This has to be a proper Systemwide Fedora Change. Given this is deviation from the upstream OpenSSH default, I'd be in favor of doing it in Fedora 31.

Comment 37 Zbigniew Jędrzejewski-Szmek 2019-04-19 08:13:18 UTC
-1 blocker, -1 fe. Doing this in rawhide would be great though.

Comment 38 Adam Williamson 2019-04-22 15:05:08 UTC
That's +1 / -6, marking as rejected. If anyone feels strongly that this is the wrong decision, please bring it up during the open floor period at the blocker review meeting in an hour or so - thanks!

Comment 39 Matthew Miller 2019-04-22 15:39:28 UTC
I strongly agree that this is not a good use for the blocker process.

I think a Change is a good idea. If this isn't getting any traction, the Prioritized Bug process may be used to raise attention. https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process

Comment 40 Jakub Jelen 2019-05-10 11:33:50 UTC
I filled the following draft for Fedora 31 system-wide change:


Please, let me know whether this looks good or there is something missing. I will send it to the change wrangler and for the review of Fesco afterward.

Comment 41 Zbigniew Jędrzejewski-Szmek 2019-05-10 14:38:13 UTC
The Change page looks nice.

Comment 42 Chris Murphy 2019-05-10 16:37:03 UTC
I think the change should apply on upgrades, i.e. Fedora 29 and Fedora 30, upon being upgraded to Fedora 31, should also have PermitRootLogin prohibit-password. There is a substantial user base that depends only on upgrades for the entire lifecycle of their hardware.

Comment 43 Tomas Mraz 2019-05-10 16:56:04 UTC
No, that does not make any sense. This would break existing configurations for users that have root user with strong password. This must not apply to upgrades (in other form than creating a .rpmnew file that contains the configuration change).

Comment 44 Jakub Jelen 2019-06-28 12:33:43 UTC
This was changed in rawhide few days back based on the Fedora 31 change:


Note You need to log in before you can comment on or make changes to this bug.