Using UCS to maintain SSH keys? SSH Key repository


#1

I have a question. We have some servers (both UCS based and NON-UCS based “*inux” servers.) Currently users have to log into each of these servers with a username/password combo, both are stored in UCS via LDAP for UCS based servers, it is stored locally for NON-UCS based servers. Management has mandated a single sign-on for all users, for the most part this is already in place for our GUI Based and Web Portal based applications via UCS. However we have a few applications that are SSH based, Management has mandated that SSH does not use username/password combo, and must use SSH keys instead. (Except for console access which is username/password based). Currently users have to generate their keys locally at their workstation then log into each server and import their keys, then setup their client of choice to use the keys.

I would like to be able to have the user generate their keys at the UCS DC, then have the SSH keys dropped into their home directory for pick up by the user for implementation at the SSH client of their choice. The end goal is to have all the keys stored in a central location, which is regularly backed up, and replicated to other DCs in case of a DC failure.

We are not talking about Certificates, we already have the UCS generating user certificates for any application that needs them, and they are stored with the user’s home directory. We are specifically dealing with JUST SSH keys for SSH based application access.

Our end goal will be to remove the use of local usernames/passwords/certificates and SSH keys on each different server , and move to a centrally managed framework for these authentication methods, either through AD, LDAP or Central Key repositories.

We also will need a method similar to this SSH key repository for generating IPSEC pre-shared keys as well. But that has not yet come down to a mandate so not going to worry about that now.


#2

Hey,

speaking from a security POV I strongly advise against central generation and storage of private SSH keys. If anyone (e.g. an admin) gains access to that list s/he can impersonate any of the accounts. The best practice is for each user to generate their own private key – that way they can also assign a passphrase to it making it truly secure. Everything else is just cargo cult security.

Back to your intended use. I’m not aware of a solution for UCS that does what you want it to out of the box. However, scripting something akin to this with udm (the command-line management tool for the domain) shouldn’t be too hard. For example:

[ol][li]Iterate over all users output by »udm users/user list«[/li]
[li]Check whether or not ~user/.ssh/id_rsa exists; if not generate one (don’t forget to set the file’s owner and permission properly!)[/li]
[li]Check whether or not ~user/.ssh/authorized_keys contains the content of ~user/.ssh/id_rsa.pub; if not add it do the file (again pay attention to final file ownership of authorized_keys)[/li][/ol]

As for key retrieval: on Linux I highly suggest mounting the user’s home directory from the UCS master via NFS. That way the user can retrieve his key from ~/.ssh/ and already log in due to 3. above.

On Windows you can access his/her home on the UCS master via Samba shares retrieving the key from ~/.ssh. Note, though, that putty (one of the most popular SSH clients on Windows) uses its own key format. If you need that format then see e.g. here how to convert the OpenSSH key format to putty’s on Linux; that would be step 4 in the list above.

Instead of using NFS you can also use some kind of deployment mechanism, of course – whatever floats your boat (from simple scp- or rsync-based scripts to full-blown management tools like Ansible/SaltStack/Puppet/Chef…).

No matter what you do I strongly suggest you enable LDAP as a user database (NSS) and authentication (PAM) backend for the non-UCS Linux servers if you haven’t done so already. That way you won’t have to manage users on the non-UCS Linux boxes manually, their UIDs and GIDs will be consistent across machines and you wouldn’t even have to store passwords locally on those machines either.


#3

We already have PAM/LDAP in place for our non-UCS linux systems, we have UCS AD in place for Windows systems.

The plan is to have all keys are already generated with passphrase as the users LDAP password, and this is changed every 90 days with the users password (keys will be regenerated too)

We plan to drop users SSH keys into their home directory which users have access to already via automout or windows mapped drives.

We need to have a central repository so we can backup keys, we also need to have it because corporate policy states that when a user is removed/leaves the company, we are to immediately lock the user account, and then delete it after 30 days, we need to have the keys get deleted when the home directory is removed. Even though the key is invalid once the user is locked out of the account, we need to destroy all traces of the user at that 30 day mark, including keys, passwords and applications access.

We don’t want user to generate their own keys, as they tend to lose them, delete them or otherwise screw them up. We’d like to back them up in our normal backup process (encrypted backups).

In all cases user passwords changed every 90 days and their keys will also be regenerated every 90 days.


#4

Hi,

I havent tried it by myself, but it looks that privacyIDEA, which is available in the Appcenter, is able to handle SSH keys.
SSH Key Management with privacyIDEA.
It doesnt look like the generation of the keys is handled but at least it might be an option to get a better handling of the keys on the server side.

Best Regards,
Dirk Ahrnke


#5

You have pretty specific requirements. I doubt you’ll find a solution that fulfills all of those out of the box. From the top of my head I can think of at least two points where your company’s requirements clash with how UCS does things:

[ol][li]Passwords aren’t stored in plain text but only hashed. In order for the generated key to have the same password as the user account you’d have to hook into all the ways a user can change his/her password, among them:
[ul][]The admin portion of the management console[/li]
[li]The user portion of the management console (users can log in in the web interface and change their password there)[/li]
[li]The PAM mechanisms (think of command-line “passwd”)[/li]
[li]The Windows portion (changing the password directly in Windows which communicates with Samba 4; Samba 4 updates its own LDAP directory which in turn is synchronized to the OpenLDAP directory)[/li][/ul][/
:m]
[li]A user’s home directory is actually not created the moment you create the user but the first time he/she logs in (it’s done via a PAM module). Such a login can be via ssh, IMAP or access to the Samba server.[/li][/ol]

I’m not saying that it’s impossible, but that you’ll probably have to develop your own customized implementation.


#6

BTW, about the requirement of re-generating SSH keys every three months. I consider this to be a mistake, especially in combination with the requirement of having to remove all traces of users who have left the company. Think of the authorized_keys file. Users can place their current key there for password-less login, you most likely know the mechanism. However, when the key changes every three months then users will have to re-add their new keys to those files all the time. Additionally you will have to remember all the SSH keys of all the users that have ever been issued in order to be sure to have wiped all of them from authorized_key files.

Of course this doesn’t apply if users may only ever log in with their own account and not to other accounts, then that user’s own authorized_keys file is affected, but as soon as another account comes into play (doesn’t have to be a personal account – could be root on a test machine or www-data on a deployment server etc.) you’ll have much more to do than if you only had a single SSH key.

Additionally you can blacklist public SSH keys on SSH servers. This functionality is made ineffective by changing SSH keys regularly.

I guess that it’s probably not in your power to change those policies, but I thought I’d point it out anyway.


#7

SSH keys are a way to identify trusted computers, without involving passwords. The steps below will walk you through generating an SSH key and adding the public key to your GitHub account.