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.
I answered this in one of the former patches, so I don't want to repeat it here too.
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). -- Erik Skultety