33

We are looking to switch to key-based management of SSH logins, and wonder if there any key-management systems which would allow us to centrally manage the access keys world-wide.

The system should ideally allow issuing key per client, and revoking them if needed, updating server machine keys on fly.

Does anyone know of such a system, either commercial or open source?

NOTE: To clarify, we need the key management for pretty large amount of cloud servers (EC2-like), and a small amount of service users. I guess LDAP + patch suggest below might be the way to go.

Improve this question
5
  • 8
    Is it only me who thinks that "private-keys and cloud" are like "drink and drive". Both make fun separately but never go together.
    – mailq
    Aug 23, 2011 at 20:11
  • 1
    "Cloud" is probably the wrong word -- it sounds like what they want is centralized authentication, with worldwide consistency.
    – voretaq7
    Aug 23, 2011 at 20:21
  • Hi. Exactly - that what we looking for.
    – SyRenity
    Oct 20, 2011 at 11:11
  • I have been struggling with this issue with some of my customers hybrid environments. There is also the question of where to keep the OPenLDAP or central instance in a cloud deployment? I have been using webmin of all things as a key management tool, and a chef cookbook to sync keys out to nodes.
    – Tom
    Mar 3, 2012 at 1:55
  • Userify covers what you're looking for (see serverfault.com/questions/647797/…)
    – fatal_error
    Nov 28, 2014 at 14:37

5 Answers 5

Reset to default
11

There are plenty of ways of doing this. LDAP key storage has been mentioned a couple of times, and I've done that and it works, as far as it does. LDAP has it's own management curiosities, though, which take some learninating.

I'm a big fan of simple, robust servers that have minimal external network dependencies for simple things like authenticating administrators, so I lean towards a far more robust SSH key distribution strategy -- I have the configuration management system take care of it. Everyone's public key is kept in the configuration management system, and wherever the person needs to be able to login, their key is added. The config system also knows to remove keys that aren't specified, so when someone leaves or their key changes, it's a simple matter of removing the key configuration and on the next config system run, the key is removed.

Improve this answer
9
  • This approach is certainly a good one, and as Womble points out it's got an advantage in that servers stay up and running (and accessible) in the event LDAP is down -- Every LDAP-backed system should (dare I say must) have at least one user whose keys are pushed out the way Womble describes. The downside is that you have to do a config run to de-authorize users. Not a problem for an "emergency account" with only a few authorized users. Bigger problem for a large number of accounts :)
    – voretaq7
    Aug 24, 2011 at 2:31
  • 1
    You really have to have a way to trigger mass config runs anyway, so it shouldn't be a big deal to do it for an account change.
    – womble ♦
    Aug 24, 2011 at 8:11
  • I agree, unfortunately business needs/mentalities don't: Paranoia at many places (mine included) dictates that config pushes happen during off-hours but new staff/leaving staff can happen any time :-/
    – voretaq7
    Aug 24, 2011 at 13:32
  • 1
    So you're happy to leave stuff broken for a business day just because you can't run a config push during the day? Just because it's common, doesn't mean it ain't stupid.
    – womble ♦
    Aug 24, 2011 at 21:42
  • 2
    Hi. So a good idea would be using Puppet for this, for example?
    – SyRenity
    Oct 20, 2011 at 11:13
26

Key pairs should be generated by the user.

The user retains the private half - you should never see it. If you have someone's private key in a form where you can read/use it you're doing security wrong.

The public half is given to you (by whatever mechanism you'd like: Web form, email, give-it-to-me-on-a-CD), to be centralized however you want. Some places store the public keys in LDAP. Others push out authorized_keys files using their deployment system.

In my environment users who need shell access give me their public keys. These keys are added to our LDAP system, and sshd consults the public key(s) listed for each user to authenticate them, by way of the LDAP Public Key patch.
When someone needs to add an additional key or revoke an existing key they let an admin know, and we take care of it. Eventually as we scale I will implement a system that lets people rotate their own public keys.

Each of our sites has a pair of LDAP servers, synchronized to our master with LDAP replication, which keeps the data consistent (and accessible) at each location.

Everything I have described can be done with open-source software. There are also commercial products that do the same thing.
You need to research the available options more thoroughly and decide which one(s) suit your environment best. If you have further (more specific) questions we can probably be more helpful.

Improve this answer
6
  • So basically, you suggest using LDAP infrastructure, with patched OpenSSH that will work with LDAP? How well this scales in production? Can it support a large amount of machines? We do need to support only a small amount of service users.
    – SyRenity
    Oct 20, 2011 at 11:15
  • 1
    @SyRenity: LDAP supports replication and clustering so it scales very well
    – Hubert Kario
    Oct 20, 2011 at 11:59
  • @SyRenity Theoretically you can support an unlimited number of machines at an unlimited number of locations (think "Really large Active Directory deployment" - AD is basically LDAP with some fashionable accessories). For service users my suggestion is to standardize them across your environment and push out standardized /etc/passwd and /etc/group files (allows the machines to operate normally and the associated services to start/run even if LDAP isn't available)
    – voretaq7
    Oct 20, 2011 at 18:22
  • @voretaq7 Meaning the service users will be managed separately from LDAP, via the configuration management?
    – SyRenity
    Oct 21, 2011 at 19:36
  • @SyRenity yes - and more importantly available for the services that use them if LDAP is down. Plan for failures or you will experience disasters.
    – voretaq7
    Oct 21, 2011 at 20:22
10

Keypairs ought not be generated anywhere but on each user's computer. Private keys are named as such for a reason.

That said, I could see a use case for some sort of centralized repository of users' public keys. One option would be to store public keys in OpenLDAP - recent versions of OpenSSH can read keys out of LDAP.

Improve this answer
3
  • 2
    Is the LDAP Public Key stuff in mainline OpenSSH now? I only know of the LPK patch (which I can vouch for - it works great). Also +1 for keeping private keys private.
    – voretaq7
    Aug 23, 2011 at 20:32
  • @voretaq7 I guess I heard it was getting merged into the mainline, but I haven't verified that myself yet. We do shared home directories via NFS, so that takes care of our key distribution for us.
    – EEAA
    Aug 23, 2011 at 21:15
  • +1 well I didn't know that. that would save me a bunch of trouble. thats now on my list of things to look into.
    – Tom
    Mar 3, 2012 at 1:54
2

There's a lot of great commercial and open source solutions, such as Userify[1] (where I work), Universal Key Manager[2], SSH Key Box[3], etc. It depends on what your needs are and if you are looking for something that centralizes management while decentralizing operation (so that your servers don't rely on a central authority to log in... in that case, you might not be able to log into any of your servers, if, say, your LDAP server is down!)

  1. https://userify.com

  2. https://www.ssh.com/products/universal-ssh-key-manager/

  3. https://www.sshkeybox.com

See also this Slant discussion:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

Improve this answer
0

I know this is a slightly older question, but Google returns it fairly high when looking for this kind of thing.

For those of us looking for a solution apart from LDAP, I just found the "SKM" project: https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .