openssh bugs - Oct 2013 - [Bug 2164] New: PermitRootLogin=without-password as default

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

            Bug ID: 2164
           Summary: PermitRootLogin=without-password as default
           Product: Portable OpenSSH
           Version: 6.2p1
          Hardware: Other
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: phil at hands.com

The current default of PermitRootLogin=yes encourages packagers
(specifically, to my knowledge, the Debian Maintainers) to ship
packages that default to PermitRootLogin=yes.

I would like to suggest that either the default be changed to
without-password to encourage packagers downstream to do likewise.

Alternatively, a recomendation in the README saying that packagers
should not ship packages that default to PermitRootLogin=yes, but
should rather default future installs to without-password, and that
where practical they should try to ensure that upgrades (at least) warn
people that they are allowing root password guessing attacks, when that
is the case.

Of course, there is a problem with simply changing this default for
upgrades, becuase some people will be logged in via a root
password-authenticated login to do the upgrade, and may lose access to
the system if the default were changed on them without warning.

This idea is apparently uncontroversial, if one judges from the
response here:

 
http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-October/031689.html

Might I suggest that if there are objections after all, that they
should probably be explored in that thread, rather than clogging up the
bug tracking system.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |djm at mindrot.org
             Blocks|                            |2360
         Resolution|---                         |FIXED

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
openssh-6.9 will default to PermitRootLogin=no

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

--- Comment #2 from Philip Hands <phil at hands.com> ---
Just out of interest, was there a reason for choosing 'no' rather than
'without-password'?

For distros at least, I think they'll all have to change that to
without-password if there's any chance that people will get the change
as part of an upgrade, since anyone that's installed ssh keys will be
pretty upset when they stop working.

Also, given that on a new install there are not going to be any
authorised keys, and one would need to have root access to place
anything in root's authorized_keys, I'm wondering what the benefit of
having this set to 'no' is supposed to be.

The only distinction that I'd expect would be that people are forced to
modify it away from 'no' in order to get things working after putting
keys in place, which is a needless irritation but more importantly,
unless they've been paying attention, they'll not switch it to
'without-password' at that point, they'll switch it to
'yes', with a
resulting needless loss of security.

I'd suggest that if there's not deemed to be a significant security
advantage associated with 'no' that it should be set to
'without-password' if only to educate users to the existence of the
option (there are still _many_ ssh users who are surprised that such an
option exists)

Cheers, Phil.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Using 'no' removes the possibility of running any of the
authorized_keys parsing code at root in the preauth path, so it removes
a bit of attack surface.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

--- Comment #4 from Philip Hands <phil at hands.com> ---
Fair point, but it still seems like a bit of a missed oportunity to me.

How about, when without-password is selected, checking for the presence
of keys in root's authorized_keys file at startup/reload and if absent
changing the setting to 'no'?

The disadvantage would be that a reload/start would be required to
notice a newly created authorized_keys file, but otherwise it would
render the two options equivelent when no keys were present.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
That seems like something an init/upgrade script might do, but I don't
think I want to do this in sshd itself.

FWIW I modified the OpenBSD installer to offer to enable
PermitRootLogin when no user accounts were created at install time, and
to set it to without-password if a root key was specified at
installation.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

--- Comment #6 from Philip Hands <phil at hands.com> ---
Fair enough.

I guess one would put without-password in the default config file.

The startup script could then check for keys allowing root logins, and
if absent, it could check that the config file still contained
without-password, and if so override that to no on the command line by
adding:

  -o PermitRootLogin=no

That, and a comment explaining what's going on in the distro's shipped
config file, should do the trick.

Would it be worth adding such a suggestion to the release notes when
explaining the intent behind the change?

Of course the script doing the checking for keys should perhaps look
out for AuthorizedKeysCommand being set too, and there may be other
wrinkles I've not thought of -- is there a way of getting sshd to spit
out the list of keys it would check for root?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.