support read-only authorized_keys

Use Case

I am trying to deploy keys that are not writable by the UNIX user they are for. In our configuration, we have a hardened SSH configuration that keeps users from modifying their own SSH keys:

AuthorizedKeysFile /etc/ssh/userkeys/%u /var/lib/misc/userkeys/%u /etc/ssh/userkeys/%u.more /etc/ssh/puppetkeys/%u

Unfortunately, the way the ssh_authorized_key type operates now is that it hardcodes the mode (0600) of the file and also the owner (whatever the user selected). So an operator has two choices, either:

-make the file owned by the user, in which case authentication works but the keys are modifiable by the user, or;

• make the file owned by root, in which case the file is not writable by the user but authentication then fails because it's not readable either

Describe the Solution You Would Like

I don't actually see why authorized_keys are 0600: they are public keys, who cares if someone reads the darn thing? Perhaps there's some leakage in the key comment, as it shows where the private key is stored and could be used for lateral movement, but the benefit of that is very much completely voided by having the authorized_keys file modifiable by the user.

Describe Alternatives You've Considered

So far, we're doing this horror:

  ensure_resource('file', "/etc/ssh/userkeys/${sandbox_user}", {
    ensure => $ensure,
    owner => 'root',
    mode  => '0444',
  })

It's not great, as we have overlapping File resources and it can cause flapping.

Additional Context

This was originally filed as MODULES-9726 and ignored for two years, then closed as not being a priority.

Start by locating the ssh_authorized_key type and the code that sets its file owner and mode. Trace the existing tests for authorized_keys permissions, then define behavior that permits root-owned files to remain readable without being writable by the target user and avoids overlapping File resources.