Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support read-only authorized_keys #92

Open
anarcat opened this issue Nov 21, 2024 · 0 comments · May be fixed by #97
Open

support read-only authorized_keys #92

anarcat opened this issue Nov 21, 2024 · 0 comments · May be fixed by #97
Labels
enhancement New feature or request

Comments

@anarcat
Copy link

anarcat commented Nov 21, 2024

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.

@anarcat anarcat added the enhancement New feature or request label Nov 21, 2024
anarcat added a commit to anarcat/puppetlabs-sshkeys_core that referenced this issue Nov 21, 2024
This is a rather bold and naive move to just plainly fix puppetlabs#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.
@anarcat anarcat linked a pull request Nov 21, 2024 that will close this issue
anarcat added a commit to anarcat/puppetlabs-sshkeys_core that referenced this issue Nov 21, 2024
This is a rather bold and naive move to fix puppetlabs#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant