Here is the situation.

I have 5000 servers broken into "groups" of 100.
Each "group" has 1 SSH key pair, that will allow access to any of the servers in the group. I have 60 users(some human, some not) that need to access all 5000 servers. The users are all on different computers, some PC (putty) some Linux(ssh).

manually: Adding a new server to a "group" seems to be simple. Adding/updating a user would be a nightmare. Adding/updating a new group would be a nightmare. Syncing group keys to user stations would be a nightmare.

ssh-agent/pageant works for a single user, on a single workstation, but doesn't seem to be scalable.

Is there software that can handle this management? Some kind of proxy perhaps? Or automated server based key retrieval protocol?


I appreciate the help so far, however I think I am not being clear or not understanding the suggestions.

Some more information: Each of the servers is a remote system with no access to the Internet and the connection speed is generally slow. Each server has only one entry in its authorized_keys file. I do not want or need individual user keys. I just want many different people to use the same key for each group. Right now we are using password authentication, and keep a list of a passwords for each group on a piece of paper. This works for our team. But it will not work if we switch to key based authentication.

Do the suggestions still make sense? If so, can you please be more specific as to implementation details.

  • 2
    Puppet? Chef? NIS?
    – tylerl
    Apr 22, 2014 at 5:58
  • @edvinas - These talk about changes on the servers. The servers configuration will be static. I need to handle changes to the users systems.
    – AllenKll
    Apr 22, 2014 at 13:16
  • @tylerl Puppet and Chef seems to be for configuring servers. Not managing key distribution to users. I'm not sure how I would implement NIS for this solution, can you explain?
    – AllenKll
    Apr 22, 2014 at 13:20
  • It's not a proper answer, but more a suggestion, so I won't post an answer for that, but I think you can manage to authenticate ssh against kerberos, which could use ldap directory, to allow, or not user to access a given server. I'm sure about the kerberos stuff, not about the granularity though. Another idea is to use the AuthorizedKeysCommand against a database, which would ease the process of adding a user, if you don't want to get into kerberos or ldap. A simple php / mysql app should be able to help you, then the AuthorizedKeysCommand would juse use mysql cli. Hope this helps.
    – aif
    May 11, 2014 at 22:41

4 Answers 4


Except it puts its own key on to the server, where instead I need it to use the keys I provide it.

I've had a couple of ppl ask for that. I added a way to specify the key pair in the latest release.



Let me know if you have any issues. Thx!

  • This is very close, and I will mark it as correct as this is the closest to an answer I've found. Except I need to specify a separate key-pair for each Profile of systems.
    – AllenKll
    Jun 11, 2014 at 15:37

Check out Userify, manages user accounts, SSH keys, and sudo roles, and doesn't need a central directory server that can go down (locking you out of all your instances.. been there.)

It's pretty easy to deploy using AWS's User Data (under the Advanced tab of instance launch) or stick it right in the UserData script for an autoscaling group or whenever you're launching an instance by hand, which is great because it works before you even log in. (Or you can just paste the one-liner into your server console, but that's not nearly as fun..)

It supports Chef, Puppet, Ansible, CloudFormation/CloudInit, and TerraForm for deployment, and each user (developer/admin/etc) gets his own web login to update multiple keys (just paste). decent interface, pretty painless.

For your specific needs (that is, large numbers of servers in individual groups over disconnected/slow web connections), I would use Userify Express self-hosted and set the poll time very high (at least 90 seconds) and create fake (non-human) users -- one for each group. Of course, you could just use real human user accounts, since you can remove human users from a large group of servers or all servers with just one click in Userify, and the users themselves can then distribute their own keys just by updating their keybox. Userify only needs https access (443 TCP) from the servers to your Userify server.

(Although you could just share keys like that, having humans have their own keys is safer; disassociating human users with individual account access breaks logging and auditing on the end servers, although it doesn't sound like that's a concern here, but most security policy frameworks like HIPAA and PCI require one human user per individual account access and ban sharing creds. Still, you can do that in Userify and even distribute private keys to groups of servers, but that method is not recommended except for service/system/automation accounts like backups or configuration management systems like Ansible.) (disclaimer: I work for Userify and helped design the original Userify model.)

  • i wonder how acceptable this solution would be a to a large organization? it seems like you're giving over the keys to the kingdom, to some third party.
    – Randy L
    Jul 24, 2015 at 17:39
  • you're only giving them public keys, not private keys. although you are giving userify the opportunity to add their own users to your servers. Apr 11, 2016 at 18:37
  • also you can install it yourself on your own server as well but it's not free unlimited like the cloud version. Jun 4, 2016 at 4:43

You could look at using LDAP with public keys http://code.google.com/p/openssh-lpk/

That would make it significantly easier to re-issue a key to a user if one gets compromised. Each user's private key can be either managed by that user or saved onto storage only they have access to (e.g. home directory).

  • This seems targeted to configure servers instead distributing keys to users. User's don't have private keys. There is one key on the server that all the users would use to access the server.
    – AllenKll
    Apr 22, 2014 at 13:23
  • Ok, I clearly misunderstood your question, so the authorized_keys on your servers will be static and your not looking for a way to change them, but your looking for a method of distributing the corresponding private keys to ~60 users?
    – Hybrid
    Apr 23, 2014 at 4:15
  • That is correct. I found Keybox. sshkeybox.com This almost does what I need. Except it puts its own key on to the server, where instead I need it to use the keys I provide it.
    – AllenKll
    Apr 23, 2014 at 17:56

Seems like Keyholder would be a very good fit for your needs.

From the wiki page:

Keyholder is a set of scripts that allow a group of users to use an SSH key without sharing the private key with the members of the group. This is accomplished by running a locked-down instance of ssh-agent, and running ssh-agent-proxy in front of it.

Once you have ssh-agent-proxy running and configured, users authenticate by setting SSH_AUTH_SOCK to point to the proxy's socket and then ssh-agent-proxy will only allow users to authenticate using a key that they are authorized to use based on their local unix group membership.

The configuration looks like this:

group-name: ["ssh:key:fingerprint"]

And the keys are stored separately, only accessible by root.

Someone with access to root must "arm" the keyholder service once after the server is rebooted, then anyone with appropriate group membership can use the keys which are stored in the keyholder ssh_agent.


Since I originally wrote this answer, keyholder has been extracted from the Wikimedia puppet repository and given the proper treatment to become a standalone project. It should be a lot easier to use now, especially for debian users as the debian packaging scripts and metadata are included in a separate branch of the source repository.

  • 2
    This looks like a link only answer ... May 5, 2016 at 18:37
  • The question is old and it already has some good answers but I was struck by how closely Keyholder fits with what @AllenKll is describing, so I shared, on the small chance that it helps. Perhaps it should have been a comment instead but it wouldn't let me post one. May 7, 2016 at 4:25
  • thanks for clarifying. Yes I understand that for a new user with a rep like only +1 you can't post comments as you would like. But how about you EDIT your answer to explain (with way more details) what the relevant parts of that link are in the context of this question? After you do, I'd be happy to re-read your answer (just add an extra comment here to ping me about it). It may help to get 1 or more upvotes ... which generate some extra reputation points for you, and which will then allow you to ... write comments anywhere. OK? May 9, 2016 at 14:58
  • Pierre: ok I expanded my answer with relevant details. May 9, 2016 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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