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.
openssh-6.9 will default to PermitRootLogin=no
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.
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.
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.
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.
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?
Close all resolved bugs after 7.3p1 release