Red Hat Bugzilla – Bug 89216
RFE: disallow root login via password using SSH
Last modified: 2017-02-21 09:09:35 EST
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):
Steps to Reproduce:
1. "# ssh 10.0.0.1" (10.0.0.1 is running RH Linux 9)
2. <entering root password>
Actual Results: User root logged in on 10.0.0.1
Expected Results: Root login using ssh should be disabled.
Red Hat Linux release 9 (Shrike)
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?
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.
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.").
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
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.
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.
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.
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.
*** Bug 97070 has been marked as a duplicate of this bug. ***
*** Bug 171595 has been marked as a duplicate of this bug. ***
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
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.
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
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.
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
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?
*** Bug 450513 has been marked as a duplicate of this bug. ***
It appears that discussion has ended. Should this bug remain open?
It was kept open so there are no duplicate bug reports created.
*** Bug 467604 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 498628 has been marked as a duplicate of this bug. ***
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.
*** Bug 817325 has been marked as a duplicate of this bug. ***
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.
*** Bug 1425285 has been marked as a duplicate of this bug. ***