Centralized management system for SSH keys?

Question

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.

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 '11 at 20:11
"Cloud" is probably the wrong word -- it sounds like what they want is centralized authentication, with worldwide consistency. — voretaq7, Aug 23 '11 at 20:21
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 03 '12 at 01:55
Userify covers what you're looking for (see http://serverfault.com/questions/647797/how-can-i-manage-ssh-keys-on-ec2/647798) — fatal_error, Nov 28 '14 at 14:37

voretaq7 · Answer 1 · 2011-08-23T20:33:27.803

24

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.

edited Aug 23 '11 at 20:33

answered Aug 23 '11 at 20:21

voretaq7

79,345
17
128
213

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 '11 at 11:15
1

@SyRenity: LDAP supports replication and clustering so it scales very well – Hubert Kario Oct 20 '11 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 '11 at 18:22
@voretaq7 Meaning the service users will be managed separately from LDAP, via the configuration management? – SyRenity Oct 21 '11 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 '11 at 20:22

score 10 · Answer 2 · answered Aug 23 '11 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.

answered Aug 23 '11 at 20:22

EEAA

108,414
18
172
242

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 '11 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 '11 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 03 '12 at 01:54

score 10 · Accepted Answer · answered Aug 23 '11 at 22:19

10

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.

answered Aug 23 '11 at 22:19

womble

95,029
29
173
228

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 '11 at 02: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 '11 at 08: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 '11 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 '11 at 21:42
No, but our test plan requires about 6 hours to complete and really can't be short-circuited so you're not shipping a new build every few hours anyway. My case may be relatively unique on SF (medical diagnostic software - We *cannot* ship broken code), but I've consulted at banks and airlines that have similar rules for super-critical systems (trading floors, customs & manifest clearing). – voretaq7 Aug 25 '11 at 15:06
2

Hi. So a good idea would be using Puppet for this, for example? – SyRenity Oct 20 '11 at 11:13
Re-thinking our requirements (high amount of machines, low amount of users), it seems that Womble approach seems the best to our case. A question, do you know of any Puppet modules that can get us started? – SyRenity Oct 21 '11 at 19:35
There's a pile of them out there, but I use my own that I've never bothered to release so I can't make recommendations. – womble Oct 29 '11 at 03:30
While voretaq answer was cool and comprehensive which I appreciate, I realized we actually need only several service accounts to access the multiple machines, so points go to womble for clean and simple suggestion. – SyRenity Nov 04 '11 at 20:41

score 2 · Answer 4 · edited Jul 04 '18 at 10:56

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!)

Centralized management system for SSH keys?

5 Answers5

Linked

Related