You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
This is a rather bold and naive move to just plainly fixpuppetlabs#92. It makes
all authorized_keys generated by this module to be readonly, publicly
readable. This might break some things, and is untested.
A proper solution would probably be to hook into a File resource there
that could be overriden properly.
Fundamentally, the problem here is that we are managing multiple
resources that hit the same actual file on disk: ideally, we'd have a
mode parameter to the resource here, but then we could get into
conflicts if multiple invocations of ssh_authorized_key use different
mode parameters.
This is a rather bold and naive move to fixpuppetlabs#92. It makes all
authorized_keys generated by this module to be readonly when generated
by root, so that Puppet can be used to deploy authorized_keys files
that are not writable by the user, yet still usable for
authentication.
This is necessary because OpenSSH drops privileges before parsing
authorized_keys. If a file is owned by root and mode `0600` (as right
now), authentication fails.
We keep the old `0600` mode for files managed by the user. For those,
there's nothing we can do anyways: if the user owns the file, they can
change the mode and rewrite the file anyways.
A proper solution would probably be to hook into a File resource there
that could be overriden properly.
Fundamentally, the problem here is that we are managing multiple
resources that hit the same actual file on disk: ideally, we'd have a
mode parameter to the resource here, but then we could get into
conflicts if multiple invocations of ssh_authorized_key use different
mode parameters.
Closes: puppetlabs#92
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:
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 theuser
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;
root
, in which case the file is not writable by the user but authentication then fails because it's not readable eitherDescribe 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 theauthorized_keys
file modifiable by the user.Describe Alternatives You've Considered
So far, we're doing this horror:
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.
The text was updated successfully, but these errors were encountered: