On Fri, 2020-04-03 at 09:43 +0200, Erik Skultety wrote:
> On Tue, Mar 31, 2020 at 05:39:45PM +0200, Andrea Bolognani wrote:
> > On Thu, 2020-03-26 at 14:33 +0100, Erik Skultety wrote:
> > > Unlike with the 'test' flavour, where the 'test' user has sudo
> > > permissions on the system, with machines set up with the 'gitlab'
> > > flavour which are intended to contact the outside world which, we don't
> > > want that. More importantly though, we must not use the default root
> > > password which is set by the install script on such machines.
> > > Therefore, set the root password to a random one as part of the gitlab
> > > flavour task, thus only allowing SSH pubkey authentication for the root
> > > account.
> >
> > I'm confused by this.
> >
> > If we want the root account to only be accessible via SSH with a
> > pubkey, then we can configure sshd accordingly: setting a random
> > password which is not stored anywhere prevents access not only via
> > SSH, but also via local access (eg. serial console), which I don't
> > think is desirable.
Turns out we already do this:
# guests/playbooks/update/tasks/users.yml
- name: 'root: Disable ssh password authentication'
lineinfile:
path: /etc/ssh/sshd_config
regexp: '^#*\s*PermitRootLogin\s*.*$'
line: 'PermitRootLogin without-password'
state: present
So it's already the case that the only way you can ssh into the
builders as root is by using pubkey authentication.
> > Moreover, the root password that is set in the first place is taken
> > from a mandatory user-provided configuration file, and I'm not sure
> > we should be condescending towards users by basically saying "we know
> > you didn't choose a secure password, so we're going to generate a new
> > one ourselves".
>
> Like I said, with these machines, we need to design them in a way where they
> can come and go easily. Once you accept that, you don't care about the root
> password as long as you have SSH access via a secure manner (at least I never
> cared with the machines I created with virt-builder, or provisioned in beaker).
> For personal machines, yes, this is inconvenient, but the sole purpose of these
> executors is to live somewhere in the cloud and do 1 job and 1 job only. I'm
> planning on proceeding with creating a cloud config for OpenStack for these
> machines which is another explanation for the password - for cloud machines,
> the root password will always be set by the cloud init script and that one can
> either be static, or random (and I have a hunch that the latter is actually
> true in production environments where other mechanism are put in use to be able
> to get root access, like SSH or a service account with sudo perms).
Sorry, I still don't get it. If the password doesn't matter because
you're going to set a new one using cloud-init, why bother replacing
the one that was set earlier?
I think we are conflating different scenarios:
* if you want to build your runner locally using 'lcitool install'
and then connect it to whatever GitLab instance, then the root
password that was configured by the user should be preserved,
because it's an explicit setting from the user;
* if you want to build qcow2 images for distribution, such that
other users can later spin them up on their cloud of choice, then
the root password must be set at instantiation time using
cloud-init or other similar mechanisms.
In neither scenario generating a random password at install time is
necessary, or helpful.
For the latter one, in particular, you'd need to ensure cloud-init
is present and enabled in the image, which is currently not the case,
so it will simply not work. You'll also want to strip out the ssh key
of the user who generated the image from authorized_keys, but I
assume something like virt-sysprep is going to be one of the steps
of the image generation pipeline and will take care of that.
--
Andrea Bolognani / Red Hat / Virtualization
