Puppet users - Feb 2010 - ssh::auth server dependency on ~/.ssh and a scoping question

Hi Andrew,

Just noticed that ssh::auth::server doesn''t require the resource for
~/.ssh
directory.  Considering the documentation says it does (in Examples -> 1.
With
account management at the bottom mentions that ''require =>
[User[$title],
File["$home/.ssh"]]'' is implicitly included in both client
and server), I
thought I''ll report it.

This works fine for ssh::auth::server because it uses a file resource for the 
~/.ssh/$filename file, so ~/.ssh is autorequired by puppet (if defined).

Also, while I''m at it, I wanted to ask a question related to scoping. 
Don''t
know if it''s another difference between puppet 0.24.8 and 0.25.x,
can''t find any
docs mentioning that.  Anyway the problem manifests itself in that simple 
manifest:

----
import "auth.pp"

include ssh::auth

Ssh::Auth::Key { length => 4096 }

ssh::auth::key { ''foo'': }

include ssh::auth::keymaster
file { ''/home/foo/.ssh'': ensure => directory, mode =>
700, owner => ''foo'',
group => ''puppet'' }
ssh::auth::client { ''foo'': group => ''foo''
}
----

this is a simplified manifest which I ran with standalone puppet and it 
produces the following error:

Only subclasses can override parameters at /root/puppet-
tests/sshauth/auth.pp:113 on node ...

The problem here is the "group => ''foo''" param
passed to ssh::auth::client.
It doesn''t really matter which parameter it is though as the issue
seems to be
that the ssh::auth::client (or ssh::auth::server) define cannot override 
properties of a resource declared in ssh::auth::key define.

I searched a bit for something on defines overriding parameters of resources 
and found a thread here on puppet-users [1] which implies this isn''t
possible.

Does that work in 0.25.x ?

[1] http://groups.google.com/group/puppet-
users/browse_thread/thread/4836b517cd7b5010


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

> Hi Andrew,
> 
> Just noticed that ssh::auth::server doesn''t require the resource
for ~/.ssh
> directory.  Considering the documentation says it does (in Examples ->
1. With
> account management at the bottom mentions that ''require =>
[User[$title],
> File["$home/.ssh"]]'' is implicitly included in both
client and server), I
> thought I''ll report it.
> 
> This works fine for ssh::auth::server because it uses a file resource for
the
> ~/.ssh/$filename file, so ~/.ssh is autorequired by puppet (if defined).
OK, thanks for pointing this out.  Looking back at it now, I think I was
probably counting on ssh_authorized_key requiring File[$home/.ssh].  But
that doesn''t seem to be explicit anywhere, so I''ll add it in
explicitly for
the next point release.  And the user too, while I''m at it.
> Also, while I''m at it, I wanted to ask a question related to
scoping.  Don''t
> know if it''s another difference between puppet 0.24.8 and 0.25.x,
can''t find any
> docs mentioning that.  Anyway the problem manifests itself in that simple 
> manifest:
> 
> ----
> import "auth.pp"
> 
> include ssh::auth
> 
> Ssh::Auth::Key { length => 4096 }
> 
> ssh::auth::key { ''foo'': }
> 
> include ssh::auth::keymaster
> file { ''/home/foo/.ssh'': ensure => directory, mode
=> 700, owner => ''foo'',
> group => ''puppet'' }
> ssh::auth::client { ''foo'': group =>
''foo'' }
> ----
> 
> this is a simplified manifest which I ran with standalone puppet and it 
> produces the following error:
> 
> Only subclasses can override parameters at /root/puppet-
> tests/sshauth/auth.pp:113 on node ...
> 
> The problem here is the "group => ''foo''"
param passed to ssh::auth::client.
> It doesn''t really matter which parameter it is though as the issue
seems to be
> that the ssh::auth::client (or ssh::auth::server) define cannot override 
> properties of a resource declared in ssh::auth::key define.
> 
> I searched a bit for something on defines overriding parameters of
resources
> and found a thread here on puppet-users [1] which implies this
isn''t possible.
> 
> Does that work in 0.25.x ?
I''ll have to spend a little time looking into this.  The whole purpose
of
the way I set up the defines and virtual resources was to be able to
override parameters.  The last time I tried it, it worked.  I guess
it''s a
conflict with the file resource in your manifest?  I''ll see what I can
figure out and get back to you.

Andrew.

-- 
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
puppet-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wednesday 24 Feb 2010 18:12:18 Andrew Schulman wrote:
> > Hi Andrew,
> >
> > Just noticed that ssh::auth::server doesn''t require the
resource for
> > ~/.ssh directory.  Considering the documentation says it does (in
> > Examples -> 1. With account management at the bottom mentions that
> > ''require => [User[$title],
File["$home/.ssh"]]'' is implicitly included in
> > both client and server), I thought I''ll report it.
> >
> > This works fine for ssh::auth::server because it uses a file resource
for
> > the ~/.ssh/$filename file, so ~/.ssh is autorequired by puppet (if
> > defined).
> 
> OK, thanks for pointing this out.  Looking back at it now, I think I was
> probably counting on ssh_authorized_key requiring File[$home/.ssh].  But
> that doesn''t seem to be explicit anywhere, so I''ll add it
in explicitly for
> the next point release.  And the user too, while I''m at it.
Actually, the user dependency is already there.  But now that you mention it, 
do you think it would be OK to make it optional, e.g. as in `if 
defined(User[foo]) { ... }`?  I actually had to disable it as I don''t
manage
users in puppet (I use nss_ldap and users are in AD).

I realize this can lead to failures when user''s home directory
doesn''t exist,
but it''s not critical, i.e. the key will simply be installed when the 
directory is created (in case of nss_ldap that is after the first time a user 
logged on).  I haven''t found a better way to deal with that yet, if you
have
better ideas, please share :)
> > Also, while I''m at it, I wanted to ask a question related to
scoping.
> > Don''t know if it''s another difference between puppet
0.24.8 and 0.25.x,
> > can''t find any docs mentioning that.  Anyway the problem
manifests itself
> > in that simple manifest:
> >
> > ----
> > import "auth.pp"
> >
> > include ssh::auth
> >
> > Ssh::Auth::Key { length => 4096 }
> >
> > ssh::auth::key { ''foo'': }
> >
> > include ssh::auth::keymaster
> > file { ''/home/foo/.ssh'': ensure => directory,
mode => 700, owner =>
> > ''foo'', group => ''puppet'' }
> > ssh::auth::client { ''foo'': group =>
''foo'' }
> > ----
> >
> > this is a simplified manifest which I ran with standalone puppet and
it
> > produces the following error:
> >
> > Only subclasses can override parameters at /root/puppet-
> > tests/sshauth/auth.pp:113 on node ...
> >
> > The problem here is the "group =>
''foo''" param passed to
> > ssh::auth::client. It doesn''t really matter which parameter
it is though
> > as the issue seems to be that the ssh::auth::client (or
> > ssh::auth::server) define cannot override properties of a resource
> > declared in ssh::auth::key define.
> >
> > I searched a bit for something on defines overriding parameters of
> > resources and found a thread here on puppet-users [1] which implies
this
> > isn''t possible.
> >
> > Does that work in 0.25.x ?
> 
> I''ll have to spend a little time looking into this.  The whole
purpose of
> the way I set up the defines and virtual resources was to be able to
> override parameters.  The last time I tried it, it worked.  I guess
it''s a
> conflict with the file resource in your manifest?  I''ll see what I
can
> figure out and get back to you.
AFAICS, ssh::auth doesn''t declare the ''${home}/.ssh''
directory and it is the
only file resource in the manifest above.

Don''t know, to be honest scoping and related issues in Puppet DSL have
always
confused the heck out of me ;)
> 
> Andrew.
> 
Thanks Andrew, let me know if I can help.


-- 
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
support@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-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 also manage users using AD (and likewise-open deployed with puppet), and
I''ve had a similar issue.
I couldn''t find an elegant way to deploy ssh public keys "only
if" the home
dir exists.

I do NOT want the user homedir to be created by puppet!  (It must be created
by likewise-open if the user logs in.)
I also don''t want errors to occur if the user folder doesn''t
exist. So I
need a "conditional" like:

"IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"

As far as I know this is not possible with puppet.

Still didn''t spend a lot of time on it but for now, the only (ugly)
alternative I could find was the suggestion to download all the available
public keys to a temp folder to every puppet client (via "file" type),
and
then via "exec" run a script that scans the existing home folders and
copy
the corresponding authorized_keys to the .ssh/ folder.

Better ideas anyone ?

Gr,
Marcello

> -----Original Message-----
> From: puppet-users@googlegroups.com [mailto:puppet-
> users@googlegroups.com] On Behalf Of Michael Gliwinski
> Sent: donderdag 25 februari 2010 10:54
> To: puppet-users@googlegroups.com
> Cc: Andrew Schulman
> Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a
> scoping question
> 
> On Wednesday 24 Feb 2010 18:12:18 Andrew Schulman wrote:
> > > Hi Andrew,
> > >
> > > Just noticed that ssh::auth::server doesn''t require the
resource
> for
> > > ~/.ssh directory.  Considering the documentation says it does (in
> > > Examples -> 1. With account management at the bottom mentions
that
> > > ''require => [User[$title],
File["$home/.ssh"]]'' is implicitly
> included in
> > > both client and server), I thought I''ll report it.
> > >
> > > This works fine for ssh::auth::server because it uses a file
> resource for
> > > the ~/.ssh/$filename file, so ~/.ssh is autorequired by puppet
(if
> > > defined).
> >
> > OK, thanks for pointing this out.  Looking back at it now, I think I
> was
> > probably counting on ssh_authorized_key requiring File[$home/.ssh].
> But
> > that doesn''t seem to be explicit anywhere, so I''ll
add it in
> explicitly for
> > the next point release.  And the user too, while I''m at it.
> 
> Actually, the user dependency is already there.  But now that you
> mention it,
> do you think it would be OK to make it optional, e.g. as in `if
> defined(User[foo]) { ... }`?  I actually had to disable it as I
don''t
> manage
> users in puppet (I use nss_ldap and users are in AD).
> 
> I realize this can lead to failures when user''s home directory
doesn''t
> exist,
> but it''s not critical, i.e. the key will simply be installed when
the
> directory is created (in case of nss_ldap that is after the first time
> a user
> logged on).  I haven''t found a better way to deal with that yet,
if you
> have
> better ideas, please share :)
> 
> > > Also, while I''m at it, I wanted to ask a question
related to
> scoping.
> > > Don''t know if it''s another difference between
puppet 0.24.8 and
> 0.25.x,
> > > can''t find any docs mentioning that.  Anyway the problem
manifests
> itself
> > > in that simple manifest:
> > >
> > > ----
> > > import "auth.pp"
> > >
> > > include ssh::auth
> > >
> > > Ssh::Auth::Key { length => 4096 }
> > >
> > > ssh::auth::key { ''foo'': }
> > >
> > > include ssh::auth::keymaster
> > > file { ''/home/foo/.ssh'': ensure =>
directory, mode => 700, owner =>
> > > ''foo'', group => ''puppet'' }
> > > ssh::auth::client { ''foo'': group =>
''foo'' }
> > > ----
> > >
> > > this is a simplified manifest which I ran with standalone puppet
> and it
> > > produces the following error:
> > >
> > > Only subclasses can override parameters at /root/puppet-
> > > tests/sshauth/auth.pp:113 on node ...
> > >
> > > The problem here is the "group =>
''foo''" param passed to
> > > ssh::auth::client. It doesn''t really matter which
parameter it is
> though
> > > as the issue seems to be that the ssh::auth::client (or
> > > ssh::auth::server) define cannot override properties of a
resource
> > > declared in ssh::auth::key define.
> > >
> > > I searched a bit for something on defines overriding parameters
of
> > > resources and found a thread here on puppet-users [1] which
implies
> this
> > > isn''t possible.
> > >
> > > Does that work in 0.25.x ?
> >
> > I''ll have to spend a little time looking into this.  The
whole
> purpose of
> > the way I set up the defines and virtual resources was to be able to
> > override parameters.  The last time I tried it, it worked.  I guess
> it''s a
> > conflict with the file resource in your manifest?  I''ll see
what I
> can
> > figure out and get back to you.
> 
> AFAICS, ssh::auth doesn''t declare the
''${home}/.ssh'' directory and it
> is the
> only file resource in the manifest above.
> 
> Don''t know, to be honest scoping and related issues in Puppet DSL
have
> always
> confused the heck out of me ;)
> 
> >
> > Andrew.
> >
> 
> Thanks Andrew, let me know if I can help.
> 
> 
> --
> 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
> support@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-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.

-- 
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 also manage users using AD (and likewise-open deployed with puppet), and
> I''ve had a similar issue.
> I couldn''t find an elegant way to deploy ssh public keys
"only if" the home
> dir exists.
> 
> I do NOT want the user homedir to be created by puppet!  (It must be
created
> by likewise-open if the user logs in.)
> I also don''t want errors to occur if the user folder
doesn''t exist. So I
> need a "conditional" like:
> 
> "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
> 
> As far as I know this is not possible with puppet.
Marcello, I want to understand your use case.  AD and LDAP seem to be
fairly common in Puppet installations, and I''d like for ssh::auth to
work
well with them.  But I''m not that familiar with them.

Are you saying that once a user is authorized for a host (or the whole
domain), the user exists on that host, but his/her home directory
doesn''t,
until they first log in?

When the user logs in, is his/her home directory automounted from a network
share?  In that case, the place to deploy the ssh keys would be in the
user''s home directory on the file server.  Or, is the home directory
created locally on the host the first time the user logs in?

It would seem to me that once a user is authorized for a host, you''d
want
to create his/her ~/.ssh/authorized_keys right away, so they can log in by
ssh.  If you can explain the sequence of how users get created and
authorized and when their home directories get created, it would help me to
address the need.

Andrew.

-- 
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
puppet-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday 25 Feb 2010 15:39:09 Andrew Schulman wrote:
> > I also manage users using AD (and likewise-open deployed with puppet),
> > and I''ve had a similar issue.
> > I couldn''t find an elegant way to deploy ssh public keys
"only if" the
> > home dir exists.
> >
> > I do NOT want the user homedir to be created by puppet!  (It must be
> > created by likewise-open if the user logs in.)
> > I also don''t want errors to occur if the user folder
doesn''t exist. So I
> > need a "conditional" like:
> >
> > "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
> >
> > As far as I know this is not possible with puppet.
> 
> Marcello, I want to understand your use case.  AD and LDAP seem to be
> fairly common in Puppet installations, and I''d like for ssh::auth
to work
> well with them.  But I''m not that familiar with them.
> 
> Are you saying that once a user is authorized for a host (or the whole
> domain), the user exists on that host, but his/her home directory
doesn''t,
> until they first log in?
Yes.
> When the user logs in, is his/her home directory automounted from a network
> share?  In that case, the place to deploy the ssh keys would be in the
> user''s home directory on the file server.  Or, is the home
directory
> created locally on the host the first time the user logs in?
That depends, it is separate from LDAP integration.  In basic setup directory 
is simply created (from /etc/skel IIRC) when the user logs in.
> It would seem to me that once a user is authorized for a host,
you''d want
> to create his/her ~/.ssh/authorized_keys right away, so they can log in by
> ssh.  If you can explain the sequence of how users get created and
> authorized and when their home directories get created, it would help me to
> address the need.
Yes, it is a bit of a chicken-and-egg problem because the way it works by 
default means first time the user has to log in using different method than SSH 
key auth.

Don''t know, I had no brilliant ideas regarding this yet ;)  As it would
seem
for it to work first time the sshd on a host would need to check/pull
user''s
key from the keymaster.
> 
> Andrew.
> 
Note that as I also mentioned before this means that there are no
''user'' type
resources in puppet (otherwise puppet would try to create them).

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

Hi Andrew,
> > "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
> > As far as I know this is not possible with puppet.
> 
> Marcello, I want to understand your use case.  AD and LDAP seem to be
> fairly common in Puppet installations, and I''d like for ssh::auth
to
> work well with them.  But I''m not that familiar with them.
> 
> Are you saying that once a user is authorized for a host (or the whole
> domain), the user exists on that host, but his/her home directory
> doesn''t, until they first log in?
The user doesn''t exactly "exist" on that host. The user and
his group
membership are ''visible'' (via AD/ldap) and he might be
authorized to login
to that host. His homedir doesn''t exist initially indeed.
> When the user logs in, is his/her home directory automounted from a
network share? 

No, although this might be possible.
But this is not default and is not what I want now.
> In that case, the place to deploy the ssh keys would be in the
> user''s home directory on the file server.  Or, is the home
directory
> created locally on the host the first time the user logs in?
Exactly.
 
> It would seem to me that once a user is authorized for a host,
you''d
> want to create his/her ~/.ssh/authorized_keys right away, so they can log
in
> by ssh.  
> If you can explain the sequence of how users get created and
> authorized and when their home directories get created, it would help
> me to address the need.
> 
> Andrew.
Let me try to explain that:
Based on a AD group membership I allow the users to login or not. If you
don''t configure that parameter on lwopen(Likewise-open) client
("require
membership of") all domain users are allowed to login. 

Next to that Likewise-open uses a hash of your ActiveDirectory-UID/GID to
generate your unix UID/GID.
Once you login to the machine for the first time lwopen will create your
homedir with the proper rights (proper hashed UID/GID and optionally
domainname). For example and "ls -ln" would show some info like:

drwxr-xr-x  953680985 953680385 /home/mydomain/myusername

Next to that lwopen would create a .k5login on that directory to allow
single sign on via Kerberos. That''s one more reason I need lwopen doing
that
and not puppet.

My whole lwopen configuration is deployed via puppet. On the machines that I
login, after my homedir is properly created, I would like to be able to
deploy my .ssh/authorized_keys as an alternative to Kerberos SSO. Btw,
that''s because Kerberos SSO has some issues, but that''s
off-topic. :)

So what I need looks simple but surprisingly difficult to
achieve:
> > "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
Is this enough info about the use case ? Ideas anyone ?

Gr,
Marcello


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

What about deploying the keys to /etc/skel?  Would that be enough for what you
want?


On Feb 25, 2010, at 8:47 AM, Marcello de Sousa wrote:
> Hi Andrew,
> 
>>> "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
>>> As far as I know this is not possible with puppet.
>> 
>> Marcello, I want to understand your use case.  AD and LDAP seem to be
>> fairly common in Puppet installations, and I''d like for
ssh::auth to
>> work well with them.  But I''m not that familiar with them.
>> 
>> Are you saying that once a user is authorized for a host (or the whole
>> domain), the user exists on that host, but his/her home directory
>> doesn''t, until they first log in?
> 
> The user doesn''t exactly "exist" on that host. The user
and his group
> membership are ''visible'' (via AD/ldap) and he might be
authorized to login
> to that host. His homedir doesn''t exist initially indeed.
> 
>> When the user logs in, is his/her home directory automounted from a
> network share? 
> 
> No, although this might be possible.
> But this is not default and is not what I want now.
> 
>> In that case, the place to deploy the ssh keys would be in the
>> user''s home directory on the file server.  Or, is the home
directory
>> created locally on the host the first time the user logs in?
> 
> Exactly.
> 
>> It would seem to me that once a user is authorized for a host,
you''d
>> want to create his/her ~/.ssh/authorized_keys right away, so they can
log
> in
>> by ssh.  
>> If you can explain the sequence of how users get created and
>> authorized and when their home directories get created, it would help
>> me to address the need.
>> 
>> Andrew.
> 
> Let me try to explain that:
> Based on a AD group membership I allow the users to login or not. If you
> don''t configure that parameter on lwopen(Likewise-open) client
("require
> membership of") all domain users are allowed to login. 
> 
> Next to that Likewise-open uses a hash of your ActiveDirectory-UID/GID to
> generate your unix UID/GID.
> Once you login to the machine for the first time lwopen will create your
> homedir with the proper rights (proper hashed UID/GID and optionally
> domainname). For example and "ls -ln" would show some info like:
> 
> drwxr-xr-x  953680985 953680385 /home/mydomain/myusername
> 
> Next to that lwopen would create a .k5login on that directory to allow
> single sign on via Kerberos. That''s one more reason I need lwopen
doing that
> and not puppet.
> 
> My whole lwopen configuration is deployed via puppet. On the machines that
I
> login, after my homedir is properly created, I would like to be able to
> deploy my .ssh/authorized_keys as an alternative to Kerberos SSO. Btw,
> that''s because Kerberos SSO has some issues, but that''s
off-topic. :)
> 
> So what I need looks simple but surprisingly difficult to achieve:
>>> "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
> 
> Is this enough info about the use case ? Ideas anyone ?
> 
> Gr,
> Marcello
> 
> 
> -- 
> 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.
> 
-- 
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.

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
> -----Original Message-----
> From: puppet-users@googlegroups.com [mailto:puppet-
> users@googlegroups.com] On Behalf Of Patrick
> Sent: donderdag 25 februari 2010 19:47
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a
> scoping question
> 
> What about deploying the keys to /etc/skel?  Would that be enough for
> what you want?
> 
> 
> On Feb 25, 2010, at 8:47 AM, Marcello de Sousa wrote:
> 
> > Hi Andrew,
> >
> >>> "IF homedir exists => deploy .ssh/authorized_keys ,
else do
> nothing"
> >>> As far as I know this is not possible with puppet.
> >>
> >> Marcello, I want to understand your use case.  AD and LDAP seem to
> be
> >> fairly common in Puppet installations, and I''d like for
ssh::auth to
> >> work well with them.  But I''m not that familiar with
them.
> >>
> >> Are you saying that once a user is authorized for a host (or the
> whole
> >> domain), the user exists on that host, but his/her home directory
> >> doesn''t, until they first log in?
> >
> > The user doesn''t exactly "exist" on that host. The
user and his group
> > membership are ''visible'' (via AD/ldap) and he might
be authorized to
> login
> > to that host. His homedir doesn''t exist initially indeed.
> >
> >> When the user logs in, is his/her home directory automounted from
a
> > network share?
> >
> > No, although this might be possible.
> > But this is not default and is not what I want now.
> >
> >> In that case, the place to deploy the ssh keys would be in the
> >> user''s home directory on the file server.  Or, is the
home directory
> >> created locally on the host the first time the user logs in?
> >
> > Exactly.
> >
> >> It would seem to me that once a user is authorized for a host,
you''d
> >> want to create his/her ~/.ssh/authorized_keys right away, so they
> can log
> > in
> >> by ssh.
> >> If you can explain the sequence of how users get created and
> >> authorized and when their home directories get created, it would
> help
> >> me to address the need.
> >>
> >> Andrew.
> >
> > Let me try to explain that:
> > Based on a AD group membership I allow the users to login or not. If
> you
> > don''t configure that parameter on lwopen(Likewise-open)
client
> ("require
> > membership of") all domain users are allowed to login.
> >
> > Next to that Likewise-open uses a hash of your ActiveDirectory-
> UID/GID to
> > generate your unix UID/GID.
> > Once you login to the machine for the first time lwopen will create
> your
> > homedir with the proper rights (proper hashed UID/GID and optionally
> > domainname). For example and "ls -ln" would show some info
like:
> >
> > drwxr-xr-x  953680985 953680385 /home/mydomain/myusername
> >
> > Next to that lwopen would create a .k5login on that directory to
> allow
> > single sign on via Kerberos. That''s one more reason I need
lwopen
> doing that
> > and not puppet.
> >
> > My whole lwopen configuration is deployed via puppet. On the machines
> that I
> > login, after my homedir is properly created, I would like to be able
> to
> > deploy my .ssh/authorized_keys as an alternative to Kerberos SSO.
> Btw,
> > that''s because Kerberos SSO has some issues, but
that''s off-topic. :)
> >
> > So what I need looks simple but surprisingly difficult to achieve:
> >>> "IF homedir exists => deploy .ssh/authorized_keys ,
else do
> nothing"
> >
> > Is this enough info about the use case ? Ideas anyone ?
> >
> > Gr,
> > Marcello
> >
> >
> > --
> > 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.
> >
> 
> --
> 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.

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

-- 
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 Thu, Feb 25, 2010 at 12:52 PM, Patrick <kc7zzv@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-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.

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-
> users@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 <kc7zzv@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-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.

-- 
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 Thu, 25 Feb 2010, Marcello de Sousa wrote:
> "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
If you don''t mind errors when you attempt to apply the manifest and the
homedir does not exist, then you could make the authorized_keys file
depend on something that fails if the homedir does not exist.

Here''s an untested example:

    # If the directory exists, then the "unless" clause in the exec
    # is satisfied, so the "command" does not run; but the overall
    # exec resource behaves as if it was successful, and anything that
    # requires this exec is happy.
    #
    # If the directory does not exist, then the "unless" fails, so the
    # "command" runs; but the command is "/bin/false", so
the command
    # reports a failure, the overall exec resource fails, and anything
    # that requires this exec will have a failed dependency and will
    # therefore not be evaluated.
    #
    exec { "fail if $homedir does not exist":
	command => "/bin/false",
	unless => "/usr/bin/test -d $homedir",
    }

    file { "$homedir/.ssh/authorized_keys":
	source => "puppet:///wherever",
	require => Exec["fail if $homedir does not exist"],
    }

--apb (Alan Barrett)

-- 
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 Friday 26 Feb 2010 09:37:28 Alan Barrett wrote:
> On Thu, 25 Feb 2010, Marcello de Sousa wrote:
> > "IF homedir exists => deploy .ssh/authorized_keys , else do
nothing"
> 
> If you don''t mind errors when you attempt to apply the manifest
and the
> homedir does not exist, then you could make the authorized_keys file
> depend on something that fails if the homedir does not exist.
> 
> Here''s an untested example:
> 
>     # If the directory exists, then the "unless" clause in the
exec
>     # is satisfied, so the "command" does not run; but the
overall
>     # exec resource behaves as if it was successful, and anything that
>     # requires this exec is happy.
>     #
>     # If the directory does not exist, then the "unless" fails,
so the
>     # "command" runs; but the command is "/bin/false",
so the command
>     # reports a failure, the overall exec resource fails, and anything
>     # that requires this exec will have a failed dependency and will
>     # therefore not be evaluated.
>     #
>     exec { "fail if $homedir does not exist":
> 	command => "/bin/false",
> 	unless => "/usr/bin/test -d $homedir",
>     }
> 
>     file { "$homedir/.ssh/authorized_keys":
> 	source => "puppet:///wherever",
> 	require => Exec["fail if $homedir does not exist"],
>     }
> 
> --apb (Alan Barrett)
> 
That''s what I''m doing now.  Generally it is sufficient to
declare a file resource
for ${home}/.ssh and depend on it.  It will fail if ${home} doesn''t
exist.

Still, it would be nice to have something better, or at least be able to tell 
puppet to ignore errors from this resource/scope.

-- 
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
support@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-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 can''t have errors.
Reporting is part of our procedure and it gets quite messy if you have
errors that should be neglected.

Gr,
Marcello
> -----Original Message-----
> From: puppet-users@googlegroups.com [mailto:puppet-
> users@googlegroups.com] On Behalf Of Michael Gliwinski
> Sent: vrijdag 26 februari 2010 11:32
> To: puppet-users@googlegroups.com
> Cc: Alan Barrett
> Subject: Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a
> scoping question
> 
> On Friday 26 Feb 2010 09:37:28 Alan Barrett wrote:
> > On Thu, 25 Feb 2010, Marcello de Sousa wrote:
> > > "IF homedir exists => deploy .ssh/authorized_keys , else
do
> nothing"
> >
> > If you don''t mind errors when you attempt to apply the
manifest and
> the
> > homedir does not exist, then you could make the authorized_keys file
> > depend on something that fails if the homedir does not exist.
> >
> > Here''s an untested example:
> >
> >     # If the directory exists, then the "unless" clause in
the exec
> >     # is satisfied, so the "command" does not run; but the
overall
> >     # exec resource behaves as if it was successful, and anything
> that
> >     # requires this exec is happy.
> >     #
> >     # If the directory does not exist, then the "unless"
fails, so
> the
> >     # "command" runs; but the command is
"/bin/false", so the command
> >     # reports a failure, the overall exec resource fails, and
> anything
> >     # that requires this exec will have a failed dependency and will
> >     # therefore not be evaluated.
> >     #
> >     exec { "fail if $homedir does not exist":
> >       command => "/bin/false",
> >       unless => "/usr/bin/test -d $homedir",
> >     }
> >
> >     file { "$homedir/.ssh/authorized_keys":
> >       source => "puppet:///wherever",
> >       require => Exec["fail if $homedir does not exist"],
> >     }
> >
> > --apb (Alan Barrett)
> >
> 
> That''s what I''m doing now.  Generally it is sufficient to
declare a
> file resource
> for ${home}/.ssh and depend on it.  It will fail if ${home}
doesn''t
> exist.
> 
> Still, it would be nice to have something better, or at least be able
> to tell
> puppet to ignore errors from this resource/scope.
> 
> --
> 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
> support@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-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.

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

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-
> > users@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 <kc7zzv@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-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.
> 
-- 
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
support@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-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.