Skip to content

support read-only authorized_keys #92

@anarcat

Description

@anarcat

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions