Bug #1549

ssh_authorized_keys provider creates keys-file with root ownership

Added by Paul Boven over 3 years ago. Updated over 3 years ago.

Status:Rejected Start date:09/02/2008
Priority:Normal Due date:
Assignee:Francois Deppierraz % Done:

0%
Category:ssh
Target version:-
Affected Puppet version:0.24.4 Branch:
Keywords:
Votes: 0

Description

Trying to distribute a ssh_authorized_key with puppet, but the provider creates the file with ‘root’ ownership, with mode 0600, even when creating a .ssh/authorized_keys file for another user. This means that password-less login doesn’t actually work because sshd isn’t able to read that file after dropping permissions, and also the user has no permission to edit the file. This only happens if the file did not previously exist.

Workaround: For each user, add to the manifest:

file { “/home/user/.ssh/authorized_keys” : owner => user, group => user, mode => 600,

   require => Ssh_authorized_key["user@hostname"] }

(The ‘require’ might not be absolutely necessary if puppet does not change ownership of the file once it is created.)

This is on puppet 0.24.4 (Debian Etch backports)

History

#1
Updated by James Turnbull over 3 years ago

  • Category set to ssh
  • Status changed from Unreviewed to Accepted
  • Assignee set to Francois Deppierraz

#2
Updated by AJ Christensen over 3 years ago

  • Status changed from Accepted to Needs More Information

My testing shows that ssh_authorized_keys, when creating an authorized key for a named user (in this case, steven):

node "junglist.gen.nz" {
  ssh_authorized_key {
  "aj@junglist.gen.nz":
    user => steven,
    type => "ssh-dss",
    key => "AAAAB3NzaC1kc3MAAACBAM/ihK4x0EXctmf8DgDskp4bAIrQOiDg80d74tIh5md8ZToVYVrrJ8YiXEOFldkFGRRmNWdLXSsSEh7yyNpWIu/Tc3S6Me8qWrUuGWXdZxx2sUkcOqU+AN6Zhj9piCmwSxZ0LEOaRkbp5U5bPSaA7l2vB3g098L4T1Hm4GULU8rdAAAAFQCl/skb6W0v7zEFJGzhTIRPOHhvUQAAAIEAwH9hXI9hTU4ImqA1p9Qjr0a3mZST5hEXkDrKZ4PerWUzDCHasXi3OQoNaYDQ4VuWWrqIfDWKGBrXNWmwDkwLefMkLc7+TgR/E05MM09ZbqIPUUQVjZAtMfUsyzCA8RlA873b8r5LBAAHgzHV/B9Y3+E9tfrKDWPkQeLkWo56G1kAAACAQozVW/05RB75RPWoffzDEiXZOkmiXdO6rb/H8AiCfUvkEy+5+8+8OLIrJNxWh2YIKcN3CJ4yJ4SYmqt2r9qm8Wq9pOcoR0o5Ulubnc2Vl9EhyIioWSgAWRK9BQv3khKCOabC7C5kwf42Yv/cfwE9L7txPZoV1LM3s12OD01zHaA=",
    ensure => present;
  }
}

puppet/puppetmaster generated the following folders and files (which were previously nonexistent)

root@junglist (branch: master) /etc/puppet# puppetd -t --no-noop
notice: Ignoring --listen on onetime run
info: Retrieving plugins
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //File[/var/lib/puppet/modules]/ensure: created
notice: //File[/var/lib/puppet/modules/README]/ensure: created
notice: //Modules_dir[ntp]/File[/var/lib/puppet/modules/ntp]/ensure: created
notice: //Node[junglist.gen.nz]/Ssh_authorized_key[aj@junglist.gen.nz]/ensure: created
info: Sent transaction report in 0.45 seconds
notice: Finished catalog run in 1.97 second

permissions looked a little odd, but ok:

root@junglist /home/steven# ls -la .ssh/
total 12
drwx------ 2 steven root   4096 2008-09-06 23:31 .
drwxr-xr-x 7 steven steven 4096 2008-09-06 23:31 ..
-rw------- 1 steven root    786 2008-09-06 23:31 authorized_keys

Not sure this bug is valid. Works on my system:

aj@junglist ~$ ssh steven@localhost
Linux junglist.gen.nz 2.6.24-19-server #1 SMP Sat Jul 12 00:40:01 UTC 2008 i686
Last login: Sat Sep  6 16:27:46 2008 from ip-118-90-70-56.xdsl.xnet.co.nz

#3
Updated by Paul Boven over 3 years ago

That’s strange, I’ve just tested it again:

# rm /home/user/.ssh/authorized_keys
# puppetd --test
notice: //Nodecommit:host]/mark5/Ssh_authorized_key[user@host/ensure: created
# ls -l /home/user/.ssh/authorized_keys
-rw------- 1 root root 781 Sep  8 14:48 authorized_keys

And from the manifest in question:

ssh_authorized_key { "user@host" : ensure => present, user=> user, type => dsa, 
require => File["/home/user/.ssh"], key => "ABCDEFG01234==" }

And with the addition of:

file { "/home/user/.ssh/authorized_keys" : owner => user, group => user, mode => 600, 
require => Ssh_authorized_key["user@host"] }

It does work (just to show that the username in question etc. exists and works).

#4
Updated by Francois Deppierraz over 3 years ago

PaulBoven wrote:

This is on puppet 0.24.4 (Debian Etch backports)

Mmh, this type is only in 0.24.5.

Do you install it yourself ? If so, please check that you have current code because I remember seeing and fixing this bug during development.

#5
Updated by Francois Deppierraz over 3 years ago

  • Status changed from Needs More Information to Rejected

It seems that the Debian package version 0.24.4-8 miss a few bugfixes present in 0.24.5.

Please use a more recent version, such as 0.24.5 from lenny or ask from a new backported package.

Also available in: Atom PDF