Bug 89216 - (DisallowRoot) RFE: disallow root login via password using SSH
RFE: disallow root login via password using SSH
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelen
: FutureFeature, Reopened
: 97070 171595 450513 467604 498628 817325 1425285 (view as bug list)
Depends On:
Blocks: FC6Target
  Show dependency treegraph
Reported: 2003-04-21 06:58 EDT by Peter van Egdom
Modified: 2017-02-21 09:09 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-26 15:16:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter van Egdom 2003-04-21 06:58:48 EDT
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 10:22:17 EDT
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 11:18:07 EDT
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 12:16:03 EDT
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 16:45:15 EDT
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 10:46:28 EST
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 15:10:58 EDT

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 09:10:10 EST
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 15:16:20 EDT
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 03:39:50 EDT
*** Bug 97070 has been marked as a duplicate of this bug. ***
Comment 10 Tomas Mraz 2005-10-24 03:44:10 EDT
*** Bug 171595 has been marked as a duplicate of this bug. ***
Comment 11 Chris Nystrom 2005-10-24 04:40:47 EDT
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 11:18:35 EDT
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 17:24:20 EDT
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 00:53:45 EDT
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 07:47:27 EDT
*** Bug 450513 has been marked as a duplicate of this bug. ***
Comment 16 John Poelstra 2008-07-02 15:23:48 EDT
It appears that discussion has ended.  Should this bug remain open?
Comment 17 Tomas Mraz 2008-07-02 15:33:11 EDT
It was kept open so there are no duplicate bug reports created.
Comment 18 Tomas Mraz 2008-10-19 12:00:17 EDT
*** Bug 467604 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Admin XMLRPC Client 2009-03-10 05:20:37 EDT
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 06:17:46 EDT
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 06:19:42 EDT
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 03:22:49 EDT
*** Bug 498628 has been marked as a duplicate of this bug. ***
Comment 23 Scott Williams 2010-10-23 17:57:04 EDT
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 07:25:25 EST
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 02:40:54 EDT
*** Bug 817325 has been marked as a duplicate of this bug. ***
Comment 26 Jakub Jelen 2015-06-24 10:43:57 EDT
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 08:42:54 EST
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 03:32:40 EST
*** Bug 1425285 has been marked as a duplicate of this bug. ***

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