Comment 4 for bug 1866563

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).