cloud-init expects sshd service to be available in images should be in the package deps

It'd also be sane to just *not* depend on sshd.
cloud-init doesn't really depend on sshd to my knowledge, but probably does throw some warnings or not function perfectly if its not there.

nothing about cloud-init should require sshd though. it'd be good to run without it.

source issue where this came up.

https://github.com/lxc/lxc-ci/issues/132#issuecomment-596254076

In particular, user passed in cloud-config for augmenting ssh configuration in the guest (setting user ssh keys) however, it was unknown that the centos/8/cloud image did not have sshd installed.

If I'm building a template and install cloud-init; I can see either path, cloud-init does not *require* it to function, but one of the most common tasks for cloud-init does expect that there is an ssh service when users supply ssh related config.

From a packaging perspective, seems reasonable to depend on it. Alternatively, for minimal images, cloud-init does not *directly depend on it, but users can't know before launching an image that if they supply ssh config, it wont work on an image because sshd is not present but cloud-init is?

I do know that some hardened images intentionally have sshd removed, so that they cannot be accessed at all after launch. (In such cases, any changes to instances are performed by deploying new ones, rather than updating existing ones in-place.)

Being able to use cloud-init to bootstrap such images on launch is very desirable because, of course, you can't SSH in to perform bootstrapping.

IMO, the two paths forward here are: (a) if given configuration that clearly indicates that sshd is expected to be running, cloud-init should ensure that sshd is installed, or (b) cloud-init should emit clear warnings about why the configuration could not be applied, so that a user debugging the matter will be able to understand what's happened.

I would lean towards (b) here for a couple of reasons.

Firstly because I think, in general, images lacking sshd will lack it intentionally, and that omission is likely to be motivated by security concerns about running sshd in a given environment. I believe that this is likely to be intentional because a cloud image without sshd would be very obviously "broken" if SSHing in should be supported, and so unlikely to be left "unfixed" for long.

And, secondly, because installing a service that listens on a public IP address by default seems like an overreach for cloud-init; in other cases where we implicitly install things for users (Puppet, Chef, NTP), they only listen locally (or not at all).

+1 on option B

It seems really like this is Recommends.
Its not a hard depends.

On Mon, Mar 9, 2020 at 2:55 PM Ryan Harper <email address hidden> wrote:
>
> In particular, user passed in cloud-config for augmenting ssh
> configuration in the guest (setting user ssh keys) however, it was
> unknown that the centos/8/cloud image did not have sshd installed.
>
> If I'm building a template and install cloud-init; I can see either
> path, cloud-init does not *require* it to function, but one of the most
> common tasks for cloud-init does expect that there is an ssh service
> when users supply ssh related config.
>
> >From a packaging perspective, seems reasonable to depend on it.
> Alternatively, for minimal images, cloud-init does not *directly depend
> on it, but users can't know before launching an image that if they
> supply ssh config, it wont work on an image because sshd is not present
> but cloud-init is?
>
> --
> You received this bug notification because you are subscribed to cloud-
> init in Ubuntu.
> https://bugs.launchpad.net/bugs/1866563
>
> Title:
> cloud-init expects sshd service to be available in images should be in
> the package deps
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1866563/+subscriptions