Comment 2 for bug 1911680

_IF_ it is the case that cloud-init didn't previously populate absolute AuthorizedKeysFiles, then I think we can split this into two pieces: one is to remediate the regression (i.e. go from writing broken absolute files to not writing absolute files again), the other is to introduce proper support for writing to absolute files.

This latter is perhaps more complicated than it seems on its face. Keys come to cloud-init in two ways: from the cloud's metadata, and from user-data. On some clouds (e.g. EC2), the key in metadata is attached to the system but on others (e.g. GCE), every key is tied to a specific user. In user-data, they can either be specified as a top-level key (implicitly the default user's key), or against specific users. It's not immediately clear to me what the appropriate behaviour is when confronted with an absolute/global AuthorizedKeysFile: some users will expect every key specified to the system to end up in there, whereas others might be (justifiably) surprised to see keys specified for non-root users granting SSH access to the root user. We'll need to think through these semantics carefully, I think.

(Another thought: a brief examination of the sshd AUTHORIZED_KEYS FILE FORMAT docs indicate that we can't limit an authorized key to a specific user in an absolute AuthorizedKeysFile. This affects the above conversation, but also means we can't disable root SSH login in the way that we usually do.)