Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

We have 2 dozen servers and we are moving to RSA authentication. Of course, some developers, the IT, some Execs.. etc.. they all send their keys, who knows where they store them, who knows if they set passphrases etc.. Then on the server, we don't know which users have which keys and finally when somebody looses their key we need to go and manually replace them, etc etc....

I am sure there is a better way.

Aside from a commercial product I did not find a easy key managementsolution.

What are the recommended ways to do this?

share|improve this question
up vote 4 down vote accepted

We manage all our key using Puppet. Each key has a comment identifying the employee by name, and when someone loses theirs, or they leave, or whatever, we just update the manifest and Puppet takes care of clearing out the old and adding the new.

share|improve this answer

I understand you very well. When I implemented RSA authentication to access our servers just for the developers I got a really nasty days. In fact most of ordinary users still hate me for "very cryptic passwords". I can't make this work right at once, but maybe some regular notes on security will give some results and users will understand why this is needed.

You cannot do much on the users' computers. Actually, if you have administrative rights on the office computers you'll be able to perform some checks for default SSH keys paths, check running ssh-agents, key passwords, reading .ssh/config to gather additional info. But if the key is stored somewhere else, you won't be able to do much.

It was told somewhere that you should trust but check in this situation. This mostly means that you can just check sometimes how the user is accessing the server and consult him why it's necessary to use a password to secure private key, etc.

As for the server part, I'm storing all users' public keys in the LDAP database and am using patched SSH server to get public keys from LDAP. The patch is called LPK, and is not hadr to configure along with LDAP PAM authentication/authorisation. It's home page is I just rebuild the debian package with this patch (sometimes a bit modifying it to fit well) and store into our company's local repositroy which has high priority. LDAP is available to store multiple user's keys and if some key is compromised or lost I just remove its public part from the LDAP server.

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.