snappy does not include ssh-import-id preventing cloud-init user-data from importing ssh-keys

[Ryan Harper]

cloud-init user-data can specify adding users with

users:
  - name: linda
    ssh-import-keys: linda.user

and after user account creation, cloud-init invokes:

sudo -Hu linda ssh-import-id linda-user

This fails as ssh-import-id isn't part of the Ubuntu-Core image

[Gustavo Niemeyer (niemeyer)]

My system doesn't contain ssh-import-id either, and I'm on a full Ubuntu 16.04. We need to have a line somewhere in terms of what we import into the core to make functionality work, otherwise we end up with Ubuntu 16.04.

For ssh-import-id, we have functionality in snapd that does exactly that, importing a user from Ubuntu SSO and creating the local user. cloud-init should probably leverage that instead.

[Oliver Grawert (ogra)]

@ryan is there any reason why cloud-init does not actually depend on the package if it needs it to be functional ?

@gustavo seeding ssh-import-id adds about 300k to the image (including the wget dependency), that should be bearable, but i agree that duplication of functionallity isnt actually thrilling.

[Ryan Harper (raharper)]

On Thu, Sep 1, 2016 at 2:15 PM, Gustavo Niemeyer <email address hidden>
wrote:

> My system doesn't contain ssh-import-id either, and I'm on a full Ubuntu
> 16.04. We need to have a line somewhere in terms of what we import into
> the core to make functionality work, otherwise we end up with Ubuntu
> 16.04.
>

Understood.

The question remains whether or not if users feed existing cloud-init
user-data
to an Ubuntu Core image with cloud-init, what is and is not supported.

>
> For ssh-import-id, we have functionality in snapd that does exactly
> that, importing a user from Ubuntu SSO and creating the local user.
> cloud-init should probably leverage that instead.
>

Right, working on that right now.

However, for users who may not use Ubuntu SSO, but still want to import
their public key hosted in launchpad or github, would it not be reasonable
to support
that via ssh-import-id ?

Or would cloud-init need to duplicate the function of ssh-import-id to
deliver this function
when run under an Ubuntu-core image?

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1619423
>
> Title:
> snappy does not include ssh-import-id preventing cloud-init user-data
> from importing ssh-keys
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1619423/+subscriptions
>

[Ryan Harper (raharper)]

On Thu, Sep 1, 2016 at 2:27 PM, Oliver Grawert <email address hidden> wrote:

> @ryan is there any reason why cloud-init does not actually depend on the
> package if it needs it to be functional ?
>

I believe it's part of the ubuntu-server seed, so it's expected to be part
of the server image
Or at least the cloud-image, which of course includes cloud-init.

>
> @gustavo seeding ssh-import-id adds about 300k to the image (including
> the wget dependency), that should be bearable, but i agree that
> duplication of functionallity isnt actually thrilling.
>
> ** Changed in: snappy
> Status: In Progress => Confirmed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1619423
>
> Title:
> snappy does not include ssh-import-id preventing cloud-init user-data
> from importing ssh-keys
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1619423/+subscriptions
>

[Oliver Grawert (ogra)]

@ryan: well, if it breaks core functionality of cloud-init to not have it, then not having it as dependency is per definition a packaging bug ...

[Oliver Grawert (ogra)]

oh, and also note that according to mark cloud-init should only create users based on assertions and these users should never be normal system users ... so i guess you only ever want it to call "snap create-user" anyway...

from IRC:

<sabdfl_> console-conf is a console front-end to this experience
<sabdfl_> cloud-init is a metadata front-end
<sabdfl_> both of them can essentially steer the process
<sabdfl_> one is for humans on a console
<sabdfl_> the other is for orchestrators spinning stuff up remotely in clouds
<sabdfl_> but yes, snapd is the steward of device state, so ultimately both of those pathways drive things through snapd
<ogra_> hmm, but cloud-init can currently completely circumvent the assertion process ... if i tell it to add a local user it will do so ... sounds like we should block that
<sabdfl_> the base *primitive* for users is "dear snapd please create a user on this device associated with such-and-such a user in such-and-such a store"
<sabdfl_> ogra_, possibly, yes
<sabdfl_> we have to understand the gray area of classic, too, where you have both snap-friendly users and legacy UNIX-only users

so inside an ubuntu-core image cloud-init should always only talk to snapd ... outside of that it should use its normal process...

[Chad Smith (chad.smith)]

On systems without ssh-import-id, cloud-init no longer fails, but warns[1] with:
            "ssh-import-id is not installed, but module ssh_import_id is "
            "configured. Skipping module."

This was resolved as desired behavior for environments without ssh-import-id installed (of which snap core qualifies as it probably doesn't typically want custom system-level users created within the environment)

This behavior to avoid breakage in cloud-init when ssh-import-id is not installed is fixed as of cloud-init 22.4

[1] https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_ssh_import_id.py#L65

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2717