One might well ask: “Why would anyone use SSH keys in the first place, rather than an ordinary username and password combination?” The easiest and shortest answer is that they are more secure. While a password can eventually be cracked by a brute force attack, SSH keys are almost impossible to decipher by this method. While a password is what it says it is (a pass “word”) that is usually in readable format, a private SSH key can be crypted with a passphrase, so that, if an attacker ever got their hands on one, they would have to guess the passphrase also.
As every new key pair weakens the security layer of the server, their management must be taken seriously. But managing SSH keys can be a pain, without proper working processes, governance and automation inside the IT organization. The danger is that the quantity of SSH keys may not be monitored very well, and that there is no audit log concerning who used which key, and when and why. Every CISO should pause and ponder the answer to this question: “How many SSH keys are actually present in my IT organization?” I dare to claim that not many of you will know the answer. If you do, I give you my virtual thumbs up!
But it is not enough just to state that you know how many keys you have. It is only half of the equation. For maximum SSH key security, you need to be able to manage them, rotate the key pairs, deliver private keys to your users, push new public keys onto the target servers and discover new keys. And this needs to happen automatically. Without these actions, IT organizations are putting themselves in great danger. You can never be sure who is using your keys, if you cannot monitor their usage. If one of your keys were to leak to someone who wanted to exploit it, you wouldn’t know about it. IT organizations need to enhance their visibility and transparency within the IT security field. “Insider threat” is a very present danger in this modern world.
Even though governance and processes are the first thing to examine when rolling out PAM in an organization, I want to stress that you also need to be able to maximize the help of the technical system and automation. First, you need to gain a proper view of the whole IT organization’s SSH key pairs. If you use the free PAM discovery tools, this becomes much easier. Then, after the lists have been gathered, they should be audited. There will probably be some orphaned keys, some keys that are not in use anymore, and some keys that are just way too old and should be renewed. Remember, every surplus key pair increases the likelihood that someone will exploit it.
Mark out those keys that need to be removed, and onboard the usable ones to your PAM system. In technical terms, this means that a public key resides at the server side (the target), and a private key and its passphrase is vaulted in the PAM vault, where you have full control over who can access it. During the “rotation” of a key pair, the PAM system actually creates a new private/public key pair, vaults the private key and its secret, and then pushes the public key to the target server. If this is done, the possibility of someone exploiting the keys is very minimal. The rotation can be set to trigger right after it has been used, so that it renews the keys after every usage. This method is slightly reminiscent of the way that ephemeral certificates work, with the obvious exception that the keys are “always in place”. So it doesn’t respect the mindset of JIT (Just-In-Time).
The rotation can also be set to trigger on a time basis, or it can be given an expiration date, or it can be triggered manually. You can choose the key length and the encryption that will be used when creating new keys. For RSA keys, it is recommended to use at least 2048-bit key lengths, which is the same as a 617-decimal-digit-long password. It is also advisable to activate the automatic discovery of new SSH keys. So if someone were to create new keys for themselves, these keys would be automatically discovered and imported to the PAM solution. In this case, the new keys would not leave the system vulnerable to future attacks, and there would be 100% transparency concerning who is accessing the servers.
When a user needs to use a key, they will log in to the PAM system with MFA or 2FA, and select the target server and the keys. Then they will establish a connection from the PAM system to the target. The user never sees the keys, and they never get the keys for themselves. The usages can be tracked from the audit logs, and the users can be identified – who used what, and when, and what they actually did. The sessions can also be recorded on video for later auditing. So, if for some reason an insider wants to exploit their accesses, the activity will be logged. There are also features such as behavioral analytics and time-based access that can be activated in the PAM solution to achieve a few extra security layers – but let’s dig into those features next time!
PAM Technology Lead
+358 46 600 0205