Puppet users - Feb 2011 - user authorized_keys with wrong perms

Hi,

I sometimes get a strange problem with some user''s authorized_keys
file.
The file should belong to user:users_group but puppet sets it as
root:root:

i.e:

err: /Stage[os]/Computing_ssh/Ssh_authorized_key[neuroadm@si.pic.es]: 
Could not evaluate: Permission denied - /home/neuroadm/.ssh/authorized_keys


# ls -lsa /home/neuroadm/.ssh/
total 12
4 drwx------ 2 neuroadm neuro 4096 Feb  3 21:02 .
4 drwx------ 3 neuroadm neuro 4096 Feb  3 21:02 ..
4 -rw------- 1 root     root   578 Feb  3 21:02 authorized_keys

My code looks like:

                file    {
                        ''ssh_neuroadm'' :
                                name    =>
''/home/neuroadm/.ssh'',
                                owner   => ''neuroadm'',
                                group   => ''neuro'',
                                mode    => 700,
                                ensure  => directory,
                                require =>
File[''home_neuroadm''];
                        ''home_neuroadm'' :
                                name    =>
''/home/neuroadm/'',
                                owner   => ''neuroadm'',
                                group   => ''neuro'',
                                mode    => 700,
                                ensure  => directory;


''neuroadm@si.pic.es'' :
   user    => ''neuroadm'',
   key     => ''Key'';


The most strange thing is that it works sometimes and sometimes not...

The problem is solved if I remove .ssh dir and rerun puppet.

Anyone could help to find a reasonable explanation for this behaviour?

TIA,
Arnau

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 3, 3:26 pm, Arnau Bria <arnaub...@pic.es>
wrote:
> I sometimes get a strange problem with some user''s authorized_keys
file.
> The file should belong to user:users_group but puppet sets it as
> root:root:
>
> i.e:
>
> err: /Stage[os]/Computing_ssh/Ssh_authorized_key[neuro...@si.pic.es]:
> Could not evaluate: Permission denied - /home/neuroadm/.ssh/authorized_keys
>
> # ls -lsa /home/neuroadm/.ssh/
> total 12
> 4 drwx------ 2 neuroadm neuro 4096 Feb  3 21:02 .
> 4 drwx------ 3 neuroadm neuro 4096 Feb  3 21:02 ..
> 4 -rw------- 1 root     root   578 Feb  3 21:02 authorized_keys
So Puppet is sometimes failing with a permission failure while
attempting to synchronize the authorized_keys resource.  Supposing
that the agent is running as root, there aren''t very many things that
could cause it to be denied permission to access or change a file.
Here''s my short list:

1) /home is a remote filesystem (e.g. NFS), that is read-only or is
performing root squashing.  In that case, it should not be possible
for local root to change the file in any way.

2) SELinux is running in enforcing mode, and under some circumstances
users'' .ssh directories are assigned a security context that prevents
puppetd from accessing them.

The fact that removing the .ssh directory and allowing Puppet to
recreate it fixes the problem is more consistent with (2).  Even if
you think SELinux is not running or is not in enforcing mode, I
encourage you to check: package updates sometimes silently change
SELinux settings.


Cheers,

John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I ran into an issue where I was trying to set the owner and group on
authorized_keys using a file resource.  I didn''t realize that the
ssh_authorized_keys provider will automatically set the gid to the
primary group of the owner of the puppetd process (in my case, root).
So if a key was added after the file resource was processed, my group
would change from the user''s group to root.  If it was added before,
the ownership would be correct.  I removed File["~/.ssh/
authorized_keys"] and let the provider manage it.

Since you don''t have an authorized_keys file resource, I would expect
your authorized_keys to always have a group of root (if you are
running puppet as root).  I''m not sure why the owner is changing to
root though.

You may be running into this bug:  http://projects.puppetlabs.com/issues/5395

On Feb 3, 4:26 pm, Arnau Bria <arnaub...@pic.es>
wrote:
> Hi,
>
> I sometimes get a strange problem with some user''s authorized_keys
file.
> The file should belong to user:users_group but puppet sets it as
> root:root:
>
> i.e:
>
> err: /Stage[os]/Computing_ssh/Ssh_authorized_key[neuro...@si.pic.es]:
> Could not evaluate: Permission denied - /home/neuroadm/.ssh/authorized_keys
>
> # ls -lsa /home/neuroadm/.ssh/
> total 12
> 4 drwx------ 2 neuroadm neuro 4096 Feb  3 21:02 .
> 4 drwx------ 3 neuroadm neuro 4096 Feb  3 21:02 ..
> 4 -rw------- 1 root     root   578 Feb  3 21:02 authorized_keys
>
> My code looks like:
>
>                 file    {
>                         ''ssh_neuroadm'' :
>                                 name    =>
''/home/neuroadm/.ssh'',
>                                 owner   => ''neuroadm'',
>                                 group   => ''neuro'',
>                                 mode    => 700,
>                                 ensure  => directory,
>                                 require =>
File[''home_neuroadm''];
>                         ''home_neuroadm'' :
>                                 name    =>
''/home/neuroadm/'',
>                                 owner   => ''neuroadm'',
>                                 group   => ''neuro'',
>                                 mode    => 700,
>                                 ensure  => directory;
>
> ''neuro...@si.pic.es'' :
>    user    => ''neuroadm'',
>    key     => ''Key'';
>
> The most strange thing is that it works sometimes and sometimes not...
>
> The problem is solved if I remove .ssh dir and rerun puppet.
>
> Anyone could help to find a reasonable explanation for this behaviour?
>
> TIA,
> Arnau
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, 4 Feb 2011 06:30:10 -0800 (PST)
jcbollinger jcbollinger wrote:

[...]
> So Puppet is sometimes failing with a permission failure while
> attempting to synchronize the authorized_keys resource.  Supposing
> that the agent is running as root, there aren''t very many things
that
> could cause it to be denied permission to access or change a file.
Yes, agent runs as root.
> Here''s my short list:
homes are local and selinux is disabled.
 
> The fact that removing the .ssh directory and allowing Puppet to
> recreate it fixes the problem is more consistent with (2).  Even if
> you think SELinux is not running or is not in enforcing mode, I
> encourage you to check: package updates sometimes silently change
> SELinux settings.
I''m not familiar to selinux, maybe disabled is not enough... but
seems to me that it''s diasbled:
 # grep -v "#" /etc/selinux/config
SELINUX=disabled
SELINUXTYPE=targeted
SETLOCALDEFS=0 

> Cheers,
> 
> John
thanks for your reply,
Cheers,
Arnau

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>> 4 drwx------ 2 neuroadm neuro 4096 Feb  3 21:02 .
>> 4 drwx------ 3 neuroadm neuro 4096 Feb  3 21:02 ..
>> 4 -rw------- 1 root     root   578 Feb  3 21:02 authorized_keys
> 
> So Puppet is sometimes failing with a permission failure while
> attempting to synchronize the authorized_keys resource.  Supposing
> that the agent is running as root, there aren''t very many things
that
> could cause it to be denied permission to access or change a file.
> Here''s my short list:
Ah, not quite - puppet drops it privileges when installing authorized
keys and does it as the target user. There is an interesting bug in
0.25.5 that will keep puppet from filebucketing and thus installing keys
because of this behaviour, but I digress.

It''s normal for puppet to be unable to install the key in this
situation. The question is, how and why are the permissions broken?

You may succeed by having puppet fix the permissions prior to installing
keys using a file resource.

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 11, 2:24 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> Ah, not quite - puppet drops it privileges when installing authorized
> keys and does it as the target user. There is an interesting bug in
> 0.25.5 that will keep puppet from filebucketing and thus installing keys
> because of this behaviour, but I digress.
Hmm.  I obviously wasn''t considering that.
> The question is, how and why are the permissions broken?
> You may succeed by having puppet fix the permissions prior to installing
> keys using a file resource.
And that''s indeed a good question.  If Puppet is responsible, then the
ownership change must happen at a time when the agent has full
privileges.  Therefore, either
a) the agent is failing to drop privileges and assume the user''s
identity before managing the keys, or
b) the agent is changing file ownership elsewhere (probably through
management of a recursive directory resource (/home ?)), or
c) something outside Puppet is doing it.

I''d guess it''s (b), but only the OP can judge the likelihood
of (c).
I don''t think (a) is likely to be the problem.
> You may succeed by having puppet fix the permissions prior to installing
> keys using a file resource.
I''d really want to verify at least that Puppet is responsible for the
breakage in the first place.  If something else is doing it then
Puppet can fix it as needed, but that won''t prevent temporary service
outage occurring between Puppet runs.  If Puppet *is* doing it, and is
doing so because of some other resource (alternative (b), above), then
that probably signals a manifest design problem, which at minimum I
would want to document.

It should indeed be possible to fix it via a file resource.  Either a
resource for that particular file should work, or the OP''s existing
ssh_neuroadm could do it if it were made recursive (in that case, its
mode property should be set to 600; Puppet will add the execute bit
for the directory itself).

Any way around, the Ssh_authorized_key resource needs to declare a
dependency on the appropriate File resource.  "Sometimes happens and
sometimes not" is a pretty good indication that dependencies are under-
specified.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.