Hi,
I''m currently evaluating puppet for use in our server environment (2+
physical machines and something over a dozen xen instances). I want to
use it mainly for managing the ssh keys and creating and maintaining
accounts for the developers and admins (which work in like 3 groups).
So i got three groups of users (admin, test, production) or
something.
The current picture in my head like that:
(client) --ssh--> (user1@login.example.com) --ssh-->
(user1@{production,test}.example.com)
All ssh connections should be authenticated via either Public Key auth
or password. But i would prefer public key auth as this is the main
reason for us to move to puppet instead of manually managing
everything... From the login.example.com box the users should be able
to log on to their machines - preferably via public key auth - and
then allowed to use sudo to gain root rights if they are in the
appropriate group. Not every user is allowed to logon onto all
machines, e.g. a common dev would not have root rights on our
production servers with billing information on it...
I read up on user and group creation and ssh key distribution. The
only thing i cant wrap my head around is how i should handle
passwords. Until the point where sudo comes in I wont need any
passwords at all in everyday use but allowing the users to simply sudo
without a password seems a bit strange to me. So the users would need
a password. Or I could simply allow root login to our dev/test/
production machines from login.example.com thus eliminating the need
for sudo and the passwords.
Is that possible to do with puppet or have I any weird ideas in there?
I''m open for suggestions.
Greetings,
Andreas Mohrhard
--
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.
Andreas Mohrhard <anuron@gmail.com> writes:> I''m currently evaluating puppet for use in our server environment (2+ > physical machines and something over a dozen xen instances). I want to use > it mainly for managing the ssh keys and creating and maintaining accounts > for the developers and admins (which work in like 3 groups). So i got three > groups of users (admin, test, production) or something.[...]> I read up on user and group creation and ssh key distribution. The only > thing i cant wrap my head around is how i should handle passwords.I would strongly advise that you deploy an LDAP backed PAM and NSS system, rather than trying to do all this locally. While it introduces another dependency into your boot process and network, it substantially reduces the complexity of doing all this.> Until the point where sudo comes in I wont need any passwords at all in > everyday use but allowing the users to simply sudo without a password seems > a bit strange to me.It would not fit our business security requirements, but it might fit yours, and is certainly the simplest option.> So the users would need a password. Or I could simply allow root login to > our dev/test/ production machines from login.example.com thus eliminating > the need for sudo and the passwords.Bad idea: shared accounts always lead to trouble, even if it is only the trouble of having to distribute the password when someone goes to work for the competition. ;> Is that possible to do with puppet or have I any weird ideas in there? > I''m open for suggestions.The only local password distribution model I have ever seen work was where you changed the password on the master system, then distributed the changed hash to all the client machines. In the puppet world that would mean "on the puppetmaster", and "reading /etc/shadow somehow". Don''t do that though. Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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.
Here is what I use.
I have different environments, production doesn''t have access to ldap
and requires user accounts on the hosts, the office network still
installs the accounts but ldap is also used for groups and so (in case
ldap goes missing we can still access the local hosts). I have common
sudo files for types of hosts (web, sql,etc) and use sudo..local files
if I really have to get around giving someone access when I don''t want
to put them in a group (on ldap or a group of hosts).
#
# Class: users
#
import ''*.pp''
class users {
define add_user($uid,$pword,$groups) {
include virt_users
include virt_groups
$username = $title
user { $username:
comment => "puppet created account for $username",
home => "/home/$username",
shell => "/bin/bash",
uid => $uid,
password => $pword,
groups => $groups,
}
group { $username:
gid => $uid,
require => User[$username]
}
# This uses the custom fact in user/lib/facter/nfs_home.rb.
# If the fact is not nfs_home defined (ie, no nfs mount of home on
node)
# then create the home directory and add the files.
if ! $nfs_home {
file { "/home/$username":
ensure => directory,
owner => $username,
group => $username,
mode => 750,
recurse => true,
recurselimit => 2,
require => [User[$username], Group[$username]],
source => "puppet:///modules/users/home/$username"
}
file { "/home/$username/.ssh":
ensure => directory,
owner => $username,
group => $username,
mode => 700,
}
file { "/home/$username/.ssh/authorized_keys":
ensure => file,
owner => $username,
group => $username,
mode => 600,
source => "puppet:///modules/users/home/$username/.ssh/
authorized_keys"
}
}
}
}
I then break my accounts up into groups like so:
class sysAdmins inherits users {
users::add_user { "someguy":
pword => ''<a password hash from /etc/shadow or
ldap>'',
uid => UIDNUMBER,
groups => [ ''wheel'', ''some other
group'' ]
}
Then in the node definitions I include them:
node default {
include sysAdmins
}
I can override the defaults by adding another class:
class Operators inherits sysAdmins {
realize ( Group ["somevirtgroup"] )
realize ( User["somevirtuser"] )
Add_user["someguy"] { groups => [ ''wheel'',
''somevirtgroup'' ] }
}
then include that on the node:
node somenode inherits default {
include Operators
}
That will add someguy''s virtual group.
This way we get user accounts on the hosts set with passwords and ssh
keys (that individuals have created on their desktops), plus access to
sudo rules with what ever password/user/group restrictions we
require.
Cheers,
DenMat
On Sep 21, 9:43 am, Daniel Pittman <dan...@rimspace.net>
wrote:> Andreas Mohrhard <anu...@gmail.com> writes:
> > I''m currently evaluating puppet for use in our server
environment (2+
> > physical machines and something over a dozen xen instances). I want to
use
> > it mainly for managing the ssh keys and creating and maintaining
accounts
> > for the developers and admins (which work in like 3 groups). So i got
three
> > groups of users (admin, test, production) or something.
>
> [...]
>
> > I read up on user and group creation and ssh key distribution. The
only
> > thing i cant wrap my head around is how i should handle passwords.
>
> I would strongly advise that you deploy an LDAP backed PAM and NSS system,
> rather than trying to do all this locally. While it introduces another
> dependency into your boot process and network, it substantially reduces the
> complexity of doing all this.
>
> > Until the point where sudo comes in I wont need any passwords at all
in
> > everyday use but allowing the users to simply sudo without a password
seems
> > a bit strange to me.
>
> It would not fit our business security requirements, but it might fit
yours,
> and is certainly the simplest option.
>
> > So the users would need a password. Or I could simply allow root login
to
> > our dev/test/ production machines from login.example.com thus
eliminating
> > the need for sudo and the passwords.
>
> Bad idea: shared accounts always lead to trouble, even if it is only the
> trouble of having to distribute the password when someone goes to work for
the
> competition. ;
>
> > Is that possible to do with puppet or have I any weird ideas in there?
> > I''m open for suggestions.
>
> The only local password distribution model I have ever seen work was where
you
> changed the password on the master system, then distributed the changed
hash
> to all the client machines.
>
> In the puppet world that would mean "on the puppetmaster", and
"reading
> /etc/shadow somehow".
>
> Don''t do that though.
> Daniel
> --
> ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155
707
> ♽ made with 100 percent post-consumer electrons
--
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 chose to manage users with puppet. The only thing I did not like was password management. I did not want to put user''s password in the manifest files. Instead I execute two commands when a user is created (only once): set an empty password (usermod -p ''"" username) and set the password to expired (chage -d 0 username). This will force the user to set the password with the first login. I also place user''s ssh key with ssh_authorized_key (I store the public keys in the manifests) and disable password logins on the box. -- Radek -- 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 Tue, Sep 21, 2010 at 09:43:26AM +1000, Daniel Pittman wrote:> > I read up on user and group creation and ssh key distribution. The only > > thing i cant wrap my head around is how i should handle passwords. > > I would strongly advise that you deploy an LDAP backed PAM and NSS system, > rather than trying to do all this locally. While it introduces another > dependency into your boot process and network, it substantially reduces the > complexity of doing all this.I absolutely second this. Puppet modules to integrate LDAP into PAM and nsswitch are trivial to write, moving all the complexity into the LDAP servers (which aren''t really that complex and can be made robust with little effort). Without centralised authentication, managing users across a large number of systems is asking for trouble unless the number of users is small and there is little variation in their configuration. -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" -- 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 Sep 22, 2010, at 1:56 PM, Radek wrote:> I chose to manage users with puppet. The only thing I did not like was > password management. I did not want to put user''s password in the > manifest files. Instead I execute two commands when a user is created > (only once): set an empty password (usermod -p ''"" username) and set > the password to expired (chage -d 0 username). This will force the > user to set the password with the first login. I also place user''s ssh > key with ssh_authorized_key (I store the public keys in the manifests) > and disable password logins on the box.Centralized user management is usually worth the effort, but even if you don''t do that, you should probably pick a default password that isn''t blank. -- 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.