sshd should not permit root login
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openssh (Ubuntu) |
Invalid
|
Medium
|
Colin Watson |
Bug Description
As defaultly configured, /etc/ssh/
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
PermitEmptyPass
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 "PermitEmptyPas
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 "PermitEmptyPas
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.
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 generated configuration file when sshd_config file.
who asked for an automatically-
upgrading from potato (or on a new install) will have this setting in
their /etc/ssh/
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 commands- only" - see sshd(8) for more details.
"forced-
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 words does not let you log in when the root password is
makes dictionary attacks on anything but the worst root passwords impractical;
and no, PermitEmptyPass
*locked* as opposed to empty, as it is by default.)