That sounds like a path to solution indeed :)
Thanks for the tip.
I'll also be testing it on CentOS 5, hopefully shortly, I'll get back when I 
have some feedback.

On Thursday 25 Feb 2010 23:02:51 Marcello de Sousa wrote:
> 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.
> 

-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  
It is intended solely for the addressee and access to the email by anyone else 
is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or 
any action taken or omitted to be taken in reliance on it, is prohibited and 
may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail 
are subject to the terms and conditions expressed  in the governing client 
engagement leter or contract.
If you have received this email in error please notify 
supp...@henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, 
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************

-- 
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.

Reply via email to