sshd should not permit root login

Bug #25570 reported by William Ehlhardt
This bug report is a duplicate of:  Bug #45416: PermitRootLogin. Edit Remove
6
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Invalid
Medium
Colin Watson

Bug Description

As defaultly configured, /etc/ssh/sshd_config has the following line:

PermitRootLogin yes

For security's sake, it should probably be changed to

PermitRootLogin no

since nobody's even supposed to be using root at all.

Now, the line in sshd_config that (I think) prevents this from being exploitable is

PermitEmptyPasswords no

However, wouldn't it be more secure to set both options to no by default?
If the user does set a root password, then root becomes remotely accessible for
things like dictionary attacks.
If the user happens to set "PermitEmptyPasswords yes" for whatever reason, their
machine now allows passwordless root logins. Hurray!

At least, that's the theory. Since I don't know how to set the root password
back to "nothing", I haven't tested setting "PermitEmptyPasswords yes" on my own
machine and thus can't conclusively say that it's exploitable. Still, it would
probably be a good idea to set "PermitRootLogin no" by default in order to make
things more generally secure.

Revision history for this message
Colin Watson (cjwatson) wrote :

From /usr/share/doc/openssh-server/README.Debian.gz:

========================================================================
PermitRootLogin set to yes
--------------------------

This is now the default setting (in line with upstream), and people
who asked for an automatically-generated configuration file when
upgrading from potato (or on a new install) will have this setting in
their /etc/ssh/sshd_config file.

Should you wish to change this setting, edit /etc/ssh/sshd_config, and
change:
PermitRootLogin yes
to:
PermitRootLogin no

Having PermitRootLogin set to yes means that an attacker that knows
the root password can ssh in directly (without having to go via a user
account). If you set it to no, then they must compromise a normal user
account. In the vast majority of cases, this does not give added
security; remember that any account you su to root from is equivalent
to root - compromising this account gives an attacker access to root
easily. If you only ever log in as root from the physical console,
then you probably want to set this value to no.

As an aside, PermitRootLogin can also be set to "without-password" or
"forced-commands-only" - see sshd(8) for more details.

DO NOT FILE BUG REPORTS SAYING YOU THINK THIS DEFAULT IS INCORRECT!

The argument above is somewhat condensed; I have had this discussion
at great length with many people. If you think the default is
incorrect, and feel strongly enough to want to argue with me about it,
then send me email to <email address hidden>. I will close bug reports
claiming the default is incorrect.
========================================================================

I agree with Matthew on this and will not be changing the upstream default in
our packages. Sorry. You're of course welcome to change it on your own systems.

(With regard to your comments, the delay on failed login attempts generally
makes dictionary attacks on anything but the worst root passwords impractical;
and no, PermitEmptyPasswords does not let you log in when the root password is
*locked* as opposed to empty, as it is by default.)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.