Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
Control: retitle 769388 'PermitRootLogin without-password' in new installations breaks some use cases
On Thu, 13 Nov 2014 at 09:19:42 +0000, Simon McVittie wrote:
> Anyone else, please reply to #726661 if discussing pam_loginuid or
> the new clone (bug number to be determined) if discussing PermitRootLogin.
Bug#769388 is the new cloned bug, discussing PermitRootLogin.
Summarizing, the situation here is:
* Debian 7 (wheezy) and older had "PermitRootLogin yes" by default.
* New installations of Debian 8 (jessie)'s openssh-server have
"PermitRootLogin without-password" by default. This means root can log in
with a public key or similar mechanism, but root cannot log in with a
password. This is a deliberate change to improve security by avoiding
brute-force attacks on root's password, requested in
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298138>;
after all, the root account always exists with that username,
and allows accessing any user account's data, so it's a very attractive
target for brute-force attacks.
* Upgrading openssh-server from Debian 7's version to Debian 8's version
uses debconf to ask whether to update the configuration, as far as
I can see.
* However, new installations of Debian 8 do not ask which configuration
to use; they use the new one (PermitRootLogin without-password)
unconditionally.
Concrete effects reported in this bug:
* People who were used to the old configuration find the behaviour of new
installations of jessie confusing. A NEWS.Debian entry would not help here,
because new installations don't show NEWS.Debian; an entry in the
jessie release notes would be more appropriate.
* Daniel Richard G. reports that this breaks his process for installing
Linux VM images, in which the image ends up with only a root user,
so there is no less-privileged user who can su to root.
I understand the request to have debian-installer ask which configuration
to use, and I have some sympathy for that; I've been doing a bit of
installer testing in disposable VMs recently, and it's annoying to have to
log in once at the (emulated) console to switch to "PermitRootLogin yes".
However, I do think maintainers are right to err on the side of asking the
minimum feasible number of questions in the installer.
Another possibility would be to use a low-priority question that is
only shown in the "expert" installer, but can be pre-seeded.
It is already possible to put something like this on the kernel command line
when booting the installer, which might be useful:
preseed/late_command="in-target sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config"
If you are producing VM images that are designed to be cloned repeatedly,
to make those VM images secure and correct, you already need a
post-processing step to do things like deleting the ssh host key,
setting a new unique systemd/D-Bus machine ID and so on; it seems
sensible to extend that post-processing step for jessie to enable
root login with a password, or to enable SSH public-key
authentication for root by putting a specific key in
/root/.ssh/authorized_keys.
Regards,
S
Reply to: