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

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

Niels Thykier <niels@thykier.net> (2015-01-16):
> On Thu, 13 Nov 2014 11:08:45 +0000 Simon McVittie <smcv@debian.org> wrote:
> > 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.

Preseedable configuration is way lighter than (expert or not) questions,
since it's only about an extra key/value to handle in scripts, and
there's no need for translations. We have many of those, and we could
support an extra one without too much hassle.

At first glance, having this question asked in expert mode wouldn't seem
too crazy. I'm a bit worried about the timing though; this should have
been noticed and worked on way earlier (this change happened in March).

> If this is not an issue for d-i, I suppose it could be added solely in
> the openssh-server-udeb package.

Nice try. :) That udeb is here to provide ssh support during the
installation process, it doesn't quite control what's happening in the
system getting installed.

> > 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.

We can either document that late_command option (right now) or implement
something specific to be preseeded, and document it when it's done.

By the way: You wrote about the need for translations above, that applies to
the installation guide as well.


Attachment: signature.asc
Description: Digital signature

Reply to: