-
Notifications
You must be signed in to change notification settings - Fork 33
Description
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.