Skip to main content

Risks from poorly managed SSH Keys

Read Computerworld's article about a Ponemon study discussing SSH key management issues:

Even though more than half of the surveyed enterprises had suffered SSH-key related compromises, 53% said they still had no centralized control over the keys and 60% said they had no way to detect new keys introduced in the organizations. About 46% said they never change or rotate SSH keys -- even though the keys never expire.

We've talked about this before.  We love SSH - can't live without it - but key management is difficult and often fails to meet compliance standards, particularly PCI.  Some people have suggested SSH Certificates which looks interesting, but it introduces yet another identity management system and yet another authentication system.

It's much better to have all your users using the same identity management and authentication system.  One-time passcodes as a form of two-factor authentication are particularly useful in this regard as passwords tend to work in all UIs.  Certificates do not.

It is also best to a single point of user disablement, with HR able to perform it.    This points to using RADIUS as the authentication protocol of choice inside the network.  RADIUS will do the authorization in your directory (AD, LDAP) and if that passes, the authentication in a separate system.   Disabling a user in the directory is the only step required. 

For SSH, all you need to do is to configure PAM-RADIUS and tell SSH to use it.   Then you can use pam-radius for any other service that supports PAM, such as sudo.  If you add two-factor authentication to SSH, you don't have to worry about the existing keys, they would only be used for encryption, not identification, solving your key management issue.

Current rating: 2.3

Recent Posts

Archive

2024
2022
2021
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008

Categories

Tags

Authors

Feeds

RSS / Atom