[RFC] add new `adduser-ssh` command to simplify user creation

[mvo5]

In various issue (e.g. https://gitlab.com/fedora/bootc/tracker/-/issues/2) and during devconf the idea of a os-toolbox (or sdk, osbuild-sdk, osbuild, <insert-name-here> got discussed). Broadly speaking there are two use-cases for this (quoting Colin here):

1. A container usable in a container build to mutate that build, e.g. to make user creation simpler
2. A container usable outside of a container build (like bib) to perform generic tasks (but often operating on reference to an input bootc container), e.g. to make running bootc-image-builder simpler

On my way back from devconf I was drafting a quick prototype for (1) with the user-creation in mind. I picked it because it seems the highest value target, i.e. user creation with ssh is a bit complicated right now and helping our users to get started more easily (and pleasantly) seems worthwhile.

Below is this prototype and an explanation how it works. It currently is part of the "bootc-iamge-builder" container but the code could live anywhere, I have no strong options here but it does seem sensible to me to have a os-toolbox (name strawman) that would contain both the useradd-ssh (or bootc-useradd, adduser-ssh or whatever we call it) and bib.

Feedback very welcome. The code needs more unit tests (and input validation) but the added integration test is working for me within the limited scope (i.e. it does not build and image and boots/logins into it). I'm happy to flesh this out more once there is concensus that this is the right direction (and the right language as there is an argument for doing this in rust).

---

In order to add user with ssh keys to an bootc image a fairly complicated commandline is used today [0]:

FROM quay.io/centos-bootc/centos-bootc:stream9
COPY wheel-nopasswd /etc/sudoers.d
ARG sshpubkey
RUN if test -z "$sshpubkey"; then echo "must provide sshpubkey"; exit 1; fi; \
    useradd -G wheel exampleuser && \
    mkdir -m 0700 -p /home/exampleuser/.ssh && \
    echo $sshpubkey > /home/exampleuser/.ssh/authorized_keys && \
    chmod 0600 /home/exampleuser/.ssh/authorized_keys && \
    chown -R exampleuser: /home/exampleuser

With this commit this can be simplified to something like:

FROM quay.io/bootc/os-toolbox AS toolbox_stage

FROM quay.io/centos-bootc/centos-bootc:stream9
RUN --mount=type=bind,from=toolbox_stage,target=/toolbox \
  /toolbox/usr/bin/adduser-ssh --ssh-key gh:exampleuser --sudo-wheel-nopasswd exampleuser -- -G wheel

Note that anythign after -- is passed through to useradd so the user is still flexible.

[edit: also note that the --sudo-wheel-nopasswd is not implemened yet and only there to illustrate the idea behind this helper] [edit2: there is also https://gitlab.com/fedora/bootc/osbuild-cfg/ which is slightly different but has overlap]

[jlebon]

This is a neat idea, and I'm not suggesting blocking it. But one observation is that this is actually not bootable container-specific and it would make a lot of sense to have it built into existing tools instead. E.g. ssh-copy-id does almost exactly this. One could imagine something like ssh-copy-id -i key.pub foobar@localhost --direct (the only new piece there is --direct which would make it avoid SSH'ing back into the same machine and just directly manipulate the target user's .ssh directory). So then it'd just be useradd ... && ssh-copy-id .... This would be useful even outside a container context.

I'm aware of the practicalities of trying to get this into OpenSSH of course. (Though it might be easier than we think?) But the more general idea is that in this "toolbox" approach, there might be other opportunities of this kind to enhance existing tools rather than owning those pieces and having users learn more tools.

But again, yes this is a QOL improvement today. Just something to keep in mind.

[cgwalters]

could imagine something like ssh-copy-id -i key.pub foobar@localhost --direct (the only new piece there is --direct which would make it avoid SSH'ing back into the same machine and just directly manipulate the target user's .ssh directory).

I see your point, although currently ssh-copy-id does quite a lot, and --direct would be about turning much of that off.

[edit2: there is also https://gitlab.com/fedora/bootc/osbuild-cfg/ which is slightly different but has overlap]

There's a lot of overlap I think...the biggest difference conceptually is the question of whether we ship (one or more) tools that accepts (one or more) declarative config files as input, vs exposing a CLI.

These aren't mutually exclusive of course, and in some cases it may make sense to have individual CLI tools - the ssh case could very much be one of those.

One thing I think is important to consider here is that for some of this configuration, it's desirable to support both machine-specific config (i.e. injected into disk images) and generic configuration.

• time zone
• network configs
• ssh keys

All of those for example are expressible in kickstart/blueprint today, and I think it'd be nice to be able to pass one (or both) of those formats both at container build time (hence making it generic) as well as at disk image generation (bib), or with anaconda.

WDYT?

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days.

[mvo5]

Fwiw, I looked a bit around how to do this in a more upstream manner and while there was a suggestion to add it to "useradd" (c.f. https://github.com/shadow-maint/shadow/issues/663) that was rejected on the grounds of "do-one-thing-and-do-it-well".

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days.

[github-actions[bot]]

This PR was closed because it has been stalled for 30+7 days with no activity.