Dant, The ssh_config trick could be indeed the key for a workaround: AuthorizedKeysFile /etc/ssh/authorized_keys/%u
But I've tested it with a Centos 5 machine and it didn't work. I suspect the problem is the expansion of %u to the username (our usernames have the "mydomain\myuser" format). I wonder how I can debug that and see what's trying to find as user name. I've tried the following names without success: /etc/ssh/authorized_keys/myuser /etc/ssh/authorized_keys/mydomain\myuser /etc/ssh/authorized_keys/MYDOMAIN\myuser I'm still curious though if someone has a 'native' puppet workaround for this 'conditional' situation, just in case this doesn't work on a specific OS/ssh version or we face a similar problem in the future. I also wonder if there's a way to use a user list instead of one hardcoded class per user. Thanks a lot for the tip! Cheers, Marcello > -----Original Message----- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of dan trainor > Sent: donderdag 25 februari 2010 23:16 > To: puppet-users@googlegroups.com > Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a > scoping question > > On Thu, Feb 25, 2010 at 12:52 PM, Patrick <kc7...@gmail.com> wrote: > > > > On Feb 25, 2010, at 11:23 AM, Marcello de Sousa wrote: > > > Patrick, > > > > If you do that you would put all the public keys together, > wouldn't you ? > > That means users would be able to login as any other user. That > is of course > > not what you want. > > > > We need to deploy a single specific public key per user. > > > > Gr, > > Marcello > > > I guess I misunderstood your question. I thought you had a > really strange setup where you were doing just that. > > > > > Hi, Guys - > > I've been following this thread for a bit here, and I was faced with a > similar problem. Since we only have a small admin team for some 400+ > machines, this worked out well for us. However, your mileage certainly > will vary. This is assuming that you're already pulling auth > information from LDAP, as well. > > What I've done is, maintained /etc/ssh/sshd_config with a few choice > options, namely the AuthorizedKeyFile directive. Here's an excerpt > from sshd_config, which is a template in my puppet config - you'll see > why, down at the bottom: > > > Port 22 > ... > PermitRootLogin without-password (or no, depending on the machine) > ... > RSAAuthentication yes > PubkeyAuthentication yes > AuthorizedKeysFile /etc/ssh/authorized_keys/%u > PermitEmptyPasswords no > PasswordAuthentication no > ChallengeResponseAuthentication no > GSSAPIAuthentication yes > GSSAPICleanupCredentials yes > UsePAM yes > ... > DenyGroups all > AllowGroups Domain?Admins wheel <% if environment == 'dev' %> > Domain?Users <% end %> > ClientAliveInterval 300 > > > > I then have a manifest like this: > > class sshd::config { > > File { > require => Class["sshd::install"], > notify => Class["sshd::service"] > } > > file { "/etc/ssh/sshd_config": > owner => "root", > group => "root", > mode => 440, > #source => "puppet:///sshd/sshd_config", > content => template('sshd/sshd_config') > } > > file { "/etc/ssh/authorized_keys": > ensure => directory, > owner => root, > group => root, > mode => 0755, > require => Class["ldap"] > } > > } > > Further, I maintain that /etc/ssh/authorized_keys/dtrainor file (my > key) with a class similar to this: > > class sshd::users::dtrainor { > > include sshd > > file { "/etc/ssh/authorized_keys/dtrainor": > owner => 2690, // pulled from LDAP > group => root, > mode => 0600, > source => "puppet:///sshd/authorized_keys/dtrainor", > require => Class["sshd::config"] > } > > } > > > Now, I'm no programmer, and I'm certainly not a Puppet expert. But > I've gotten around the chicken-and-the-egg problem by just being able > to apply sshd::users::dtrainor to a node that this key should be > implemented on, and there it is. > > Of course I'm open to suggestion and would appreciate some feedback, > but moreover I hope this gets you pointed in the right direction. > sshd_config has many options - unfortunately RHEL uses an older sshd > version that even limits those :) > > Thanks > -dant > > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to puppet- > users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
