Fix sshd configuration with pre-existing drop-in files

[holmanb]

Bug report

This was not reported as an issue in the wild, but as a hypothetical when discussion the impacts of drop in files on Launchpad.

Cloud-init uses a hard-coded drop-in file at /etc/ssh/sshd_config.d/50-cloud-init.conf to update the sshd configuration. Pre-existing drop-in files may supersede this file. Cloud-init's implementation is buggy in the case that another drop-in file takes priority.

[TheRealFalcon]

Pre-existing drop-in files may supersede this file. Cloud-init's implementation is buggy in the case that another drop-in file takes priority.

Why would that be considered buggy? If somebody drops in 01-mything.conf, they want that to take highest priority and should be able to override anything provided by cloud-init.

[holmanb]

Pre-existing drop-in files may supersede this file. Cloud-init's implementation is buggy in the case that another drop-in file takes priority.

Why would that be considered buggy?

As written, the behavior doesn't match the docs.

If somebody drops in 01-mything.conf, they want that to take highest priority and should be able to override anything provided by cloud-init.

It just depends on how you think about it. There are tradeoffs both ways.

Cloud-init is a first-boot configuration tool. Would you rather expect the user to know what is provided on their filesystem before running cloud-init? If so, this puts more responsibility on the user to know and understand both 1) what is in their image and 2) how sshd_config works - recall that the referenced bug exists because users don't.

What if some other tool like packer decided that theirs should be 01-packer.conf, then cloud-init would be broken for a user that tries to use cloud-init to configure an image that was built with packer.

Either the docs should be updated to match the behavior, or the behavior should be updated to match the docs.