Permission denied when trying to update root's authorized_keys using puppet

user_4624905 0
Viewed 849

I'm trying to add a key to /root/.ssh/authorized_keys(it has chmod 600) using puppet. I use ssh_authorized_key resource for this.

ssh_authorized_key { 'my@mail.com':
  ensure => present,
  user   => 'root',
  type   => 'ssh-rsa',
  key    => 'myKey',
}

When I run puppet apply ... as root for the first time it throws this error:

"Error: Puppet::Util::FileType::FileTypeFlat could not write /root/.ssh/authorized_keys: Permission denied - /root/.ssh/authorized_keys",

Nevertheless it adds the above key to /root/.ssh/authorized_keys but removes all existing keys. If I run it second time it completes successfully without any errors.

What can cause such strange behavior and how can I fix this? (My OS is CentOS 6)

puppet centos
1 Answers

That puppet, running as root, cannot modify the file but can delete it strongly suggests that mandatory access controls (SELinux) are playing a part here. If SELinux is enabled in enforcing mode and puppet's SELinux execution context is not empowered to modify files labeled as /root/.ssh/authorized_keys is initially labeled, then Puppet would indeed be denied permission to write to that file.

But deleting the original file and writing a new one in its place requires only that puppet be able to modify the directory, and it is plausible that puppet would have sufficient privilege for that. The new file would perforce bear a label that allows puppet to modify it, therefore subsequent puppet runs would not suffer from the same problem.

Bottom line: this is probably an issue related to your system configuration and how you are running Puppet, not an inherent problem inside Puppet itself. If I have characterized it correctly then you can avoid the problem by running your puppet apply command in a security context that has the necessary access to all the files you want it to be able to modify, either by relabeling files to be accessible in the context you're using now or by choosing a different context. Details, if you need them, would be more appropriately sought in a different forum, such as Super User or Unix & Linux SE.

user_24022720
Related