Why would you use the puppet-esque style of management then? Just generate the complete list of authorized_keys yourself, don't let puppet modify it for you. B

Why would you use the puppet-esque style of management then? Just generate the complete list of authorized_keys yourself, don't let puppet modify it for you. But do let puppet distribute the file. It's beyond easy. But this is a distraction. Anyone that can influence the insertion of a permanent backdoor in authorized_keys is almost certainly in deep enough to not care about any specific mechanism. Being able to populate arbitrary, unaudited data on your hosts is an intolerable situation to be in. And anyway, you're wrong. The 'purge_ssh_keys' directive can be set to 'true', disabling merge. > Cert-only auth prevents this class of attack from the beginning. Cert auth is a subset of pubkey auth, which includes both. You could set AuthorizedKeysFile to 'none' but you'd have to explain how an attacker that can influence authorized_keys cannot also influence sshd_config. Of course these are different files likely populated via different mechanism, but the threat model you are implying here seems overly specific. It might work for some people but, given the tone of the article (unspecified 'you' are doing in wrong), I don't buy it.