[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases



On Thu, 13 Nov 2014 11:08:45 +0000 Simon McVittie <smcv@debian.org> wrote:
> [...]
> 

Hi,

Thanks for the summary.

CC'ing debian-boot as I suspect the "easiest" solution will involve
documentation this in the installation-guide.

> [...]
> 
> * 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:
> 
> [...]
> 
> 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.
> 

Please also keep in mind that such questions need to be translated.

I am not certain on the policy for d-i for having pre-seedable
configuration without an "expert" question.  If this is not an issue for
d-i, I suppose it could be added solely in the openssh-server-udeb package.

> 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

If we are going down this route, then let us have it documented in the
installation-guide.  If needed be, we can add a reference from the
release notes to the relevant part of the installation guide (or maybe
just a remark about it).
  Though note that the release-notes only handles upgrades between the
(soon-to-be) previous and the (soon-to-be) current release, so I firmly
believe it should be documented in the installation-guide to ensure it
is a stand-alone document.

Assuming no objections to this, let us have this reassigned to the
installation-guide package.

Simon McVittie also wrote:
> * 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.
> 

For reference, it is also documented in the release-notes (including how
to preseed the question).

~Niels


Reply to: