Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are multiple answers that effectively say that ldap should be used instead of puppet for managing actual users. I'm inclined to agree based on a scaling perspective. Onboarding new staff members should be done by support teams, not by sysadmins adding new user resources.

However, managing ssh keys and authorized keys (along with sudo access and user config files) seems like a job perfect for puppet.

What is the standard way of managing keys and config per user? Can puppet augment ldap here? What happens if an employee turns rogue and we need to revoke their key from 1000 different authorized_keys files?

share|improve this question
Why? You can always put the keys in the directory. – Michael Hampton Mar 21 '13 at 3:30
up vote 5 down vote accepted

I disagree with Graig Watson.

Creating copies of accounts means you've then got problems keeping them in sync. Having a single source for authentication information eliminates a lot of complications and LDAP is much easier to integrate into other services (web, mail etc).

In terms of sudo access - if you configure your sudoers based on groups rather than individuals then access to the facilities can easily be controlled via LDAP. It requires more forward planning - but is much easier to manage in the longer term - you manage the security policy not data files.

Making ssh keys available on other machines is best handled by using some sort of network file system - it might be NF/Samba, but replicating or shared filesystems provide the same goal (with different side-effects).

The first step should always be defining your security model - allowing local configurations gives huge scope for undermining that model.

share|improve this answer

I am very happy with:

It contains everything you need - users, sudoers, ssh keys, even selinux configuration.

share|improve this answer

I'd actually say that Puppet is a better solution than LDAP, as it doesn't have a SPoF (logins are local, but managed centrally).

In any case, for your "rogue user" scenario, you could use the ssh_authorized_key Puppet resource and ensure => absent on their key. Then use Mcollective/cron to populate this.

See doc:

The difficulty is having Puppet manage a file in the users' home directories (which may or may not exist). You could mitigate this by customising the authorized_keys file location in your SSH config (i.e. /var/lib/ssh/authorized_keys/%u).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.