Ubuntu w/o the ubuntu user

juju
1

Problem Description

One of the requests from some prospective clients was to not have a generic “ubuntu” user. We wanted to evaluate how hard it would be to set that up, and what it would break with Juju if you did create that environment.

Charm

To that end, I creating a charm lovingly called cs:~jameinel/no-ubuntu-user based on the ‘ubuntu-lite’ charm. It adds a few things:

  • An install hook that kills any processes running as the ubuntu user and then removes that user.
  • A bit of configuration so that you can optionally create an alternative user, along with either an ssh-key or an ssh-import-id to add for that user

Usage

The simple usage is:

$ juju deploy cs:~jameinel/no-ubuntu-user \
  --config username=jameinel --config ssh-import-id=jameinel

That will create a Bionic machine, remove the ubuntu user, and then create a jameinel user and run ssh-import-id jameinel as that user, bringing in my SSH keys from launchpad.

Results

After deploying this charm, as expected:

$ juju ssh no-ubuntu-user/0

Fails, because there is no ‘ubuntu’ user to connect as. However, both juju ssh and juju scp already support user@host syntax so:

$ juju ssh jameinel@no-ubuntu-user/0
$ juju scp test-file jameinel@no-ubuntu-user/0:.

Work as expected.

The other command that no longer works is:

$ juju debug-hooks

because that command used the ubuntu user to get onto the machine to run a tmux session. We currently do not support supplying an alternative user for that machine.

Note that ‘juju run’ no longer uses SSH to connect to the machine, but uses the actions infrastructure to run, run for a unit works fine:

$ juju run --unit no-ubuntu-user/1 'echo $(hostname) says hello'
juju-4eeb15-2 says hello

However, ‘juju run’ as a machine was designed to su - ubuntu before running the command, and now that the user doesn’t exist, it fails:

$ juju run --machine 2 'echo $(hostname) says hello'
No passwd entry for user 'ubuntu'

Another agent that stops working is the ssh-authkeys-updater. It wants to make sure the “ubuntu” user on every machine has the right .ssh/authorized-keys file. But obviously if ubuntu isn’t there, it cannot update. It would need to stop itself cleanly if there is no ubuntu user on the machine.

Further work

I’m still evaluating whether any other commands start failing, but so far the only obvious fallout is juju debug-hooks and juju run --machine. We can certainly consider if we want to allow passing in an alternative username (and possibly have juju run --machine run as root always/only if ubuntu isn’t available).

It would also be good to have other people test out the charm, just in case I didn’t actually publish it correctly.

2

Hi John,

Another approach someone could come up with to not have an ubuntu user is passing a cloud-init userdata config, for example:

 system_info:
   default_user:
    name: foobar
    plain_text_passwd: 'deadbeef'
    home: /home/foobar
    shell: /bin/bash
    lock_passwd: True
    gecos: Foo Bar
    groups: [adm, audio, cdrom, dialout, floppy, video, plugdev, dip, netdev]

And you set this chunk with juju model-config cloudinit-userdata, this way you could deploy any workload/charm

1 Like
3

cloud-init would be a much more logical long-term choice than custom scripting to achieve the same.

4

Thanks for the feedback.
I think it also makes sense at a model config level as it is essentially company policy.

My understanding is that the places requesting this don’t want any default user. What they actually want is the machines to only have site users authenticated by something like LDAP.

It might be interesting to have a “disable-ubuntu-user” in Juju that would allow us to not create it in the first place. And then maybe they could just use ‘juju run’ to configure their auth.
Or possibly it’s a cloud init script. But it starts getting complex enough that you really want more than just a script snippet in a config entry, I think.

5

I think cloud-init will skip user’s creation if the users config is empty

users: []
6

A common scenario I encountered in enterprise environments is management of users via (unsurprisingly) some form of a directory (OpenLDAP, AD etc.) with various PAM plugins (SSSD, Centrify, etc.) used on pre-built Ubuntu images for authentication. I am yet to encounter a scenario where this is a post-deployment configuration (done, example, via cloud-init userdata) rather a configuration done on a pre-built image with a Juju manual provider used.

This is just a comment on use-cases - I don’t think it should be problematic for Juju agents or charms to use any users available via PAM so long as there is passwordless sudo to do priveleged actions.