Comment 6 for bug 1911680

Thanks Seth, your thoughts are much appreciated!

On Fri, Jan 15, 2021 at 12:03:49AM -0000, Seth Arnold wrote:
> Is it correct that openssh configured with AuthorizedKeysFile
> /etc/ssh/authorized_keys will allow any of the listed keys to log in as
> any user account that can read /etc/ssh/authorized_keys?

This is my understanding, yes.

> What happens if the sshd_config has multiple AuthorizedKeysFile
> settings, within different Match blocks? Admins could write the Match
> blocks to have different AllowUsers or AllowGroups, etc.

This is an excellent question, which I had not considered previously.
We'll need to consider these potential configurations when figuring out
how to reintroduce this support.

(It is perhaps worth noting that cloud-init only performs its SSH key
configuration at first boot: while it's certainly possible that people
could bake images containing complex configs (and we therefore need to,
at the very least, not break them), if they are applied by config
management, or manually, then they won't be present when the relevant
cloud-init code runs.)

> There seems to be so much flexibility in how these can be combined that
> trying to codify cloud-init handling of AuthorizedKeysFile settings
> different from the defaults may be quite difficult to get correct.

My understanding is that the problem the submitter was trying to fix is
the simple case where there is a single non-default AuthorizedKeysFile
setting, which applies globally. Provided we can (a) reliably identify
which AuthorizedKeysFile setting (if any) applies globally, and (b)
reliably identify that the value of the setting is user-specific, then I
think we can handle that particular case.

(a) will require more investigation, but (b) we can do, I think: if the
setting is relative or contains %h, %u or %U, then it is user-specific.

It is clear to me that we cannot provide generic handling of anything
but the most simple cases, without getting into a security minefield. If
folks want to apply more complex configs, then they should treat
cloud-init's authorized key support as bootstrapping instance access,
and apply such configurations separately. (Such application could happen
using `runcmd` or `write_files` cloud-init config, which would still
allow such SSH configurations to be applied without use of a separate
tool.)