SSH User Keys: Strategies for Taking Control

Featured article by Matthew McKenna, Chief Strategy Officer, SSH Communications Security

A common misperception about SSH user key management concerns the need to find and control all the private keys in an environment. The idea here is that, since private keys are like passwords, it’s possible to manage them using the same methods. Once all the private keys are well controlled, safety has been achieved. What may initially seem like common sense does not hold up under inspection.

Think of a private key as the key to your house and the public key as the lock to your door. Now, of course private keys are important. Let’s face it: without the key to the house, you still can’t unlock the door. The point is, however, that when you lose the key to your house, to truly be safe, you need to change both the lock and the key. You need to know who owns the key and, more importantly, what the user of the key may do when they enter your house.

The Sony breach provides a real-life example. It is thought that the attack was caused by a spearfishing incident. However, once the malicious actors had access to the environment, they grabbed numerous private keys. Some of these private keys provided access to critical information such as payroll and other important applications.

SSH User Keys Are Not Passwords

This all could have been avoided if the private key had been better controlled, right? Well, yes and no. Let’s explore this more closely to understand why we might be misguided in our intense focus on finding and controlling all the private keys in our environment.

It’s important to keep in mind that, in fact, SSH user keys are not passwords. There are some very significant differences between them that require us to handle them differently. There are five key differences to consider:

1. Passwords grant access to the operating system level without additional restrictions. SSH user keys can control both access and privilege levels.

2. Passwords are related to user accounts. SSH user keys don’t have to be.

3. Passwords usually have expiration times. SSH user keys don’t.

4. Passwords cannot be generated without oversight. SSH user keys frequently can.

5. Passwords are mainly used for interactive authentication. SSH user keys are most frequently used for machine-to-machine authentication.

Another important fact: it is difficult if not impossible to find all the private keys across our environments. The following simple command “ssh -i /path/to/id_priv_key_rsa user2@serverB” demonstrates exactly how difficult this is. This command essentially provides us with the ability to place a private key almost anywhere. It can sit on our desktop. It can sit in a folder. It can sit on a network file system. It is easily transportable on a USB stick. It can essentially be hidden almost anywhere, and this is exactly the challenge. How to effectively scan to find all the private keys or to force the standardization of the location of the private key are both extremely challenging if not impossible.

Imagine that it were possible to discover all the private keys in our environment and even store them all in a secure central vault. Unless we can actually prohibit the ability to generate new key pairs by administrators, it is very easy to come through the intended jump host or privileged access management architecture, access your target server and drop in a new key pair which would allow you now to bypass that architecture in the future. This is a very common scenario.

The Challenge of M2M

It does provide benefits and decrease risk to store private keys in a secure vault, and it’s a solid approach for interactive usage. The challenge is applying this same approach for machine-to-machine connections, which tend to make up about 80-90 percent of the SSH user key-based authentication within enterprises today. The risk of breaking automated processes by vaulting private keys is high, and efforts to re-script application-to-application connections to look for that private key in a centralized vault is again a daunting and burdensome task for any organization.

That’s not a workable scenario, so what is? Going back to the principle of controlling the locks to your house, the most important controls related to access are placed on the public key side of the equation.

There are several options available when provisioning a key pair that in the majority of cases are not used but could easily be applied. First, it is possible during the generation of an SSH user key pair to place what is know as an IP source restriction on that key. This means that for that key pair, the private key may only access that target server from that specific IP. So, if the private key were stolen and it attempted to authenticate from another IP, the authentication would not work. In a simple step, we have just decreased the attack vector of the key significantly.

In addition, putting a command restriction on the public key is another easy option. This basically restricts the authenticated session to running the commands it is intended to. For example, if we lock down a key from a command point of view to only allow that authenticated session to run SFTP, then we have eliminated the possibility, should the private key be stolen or lost, of it being misused to run other commands, which could affect the resilience of our environment.

SSH Configuration Management

We can decrease risks around transitive trust by taking the combination of IP source restrictions and forcing what commands SSH user key-based authentication can use. Having a clear understanding of transitive trusts in our environment helps us clearly understand the implication should a private key be leaked or stolen.

A final action is to take advantage of the many controls available when it comes to SSH configuration management. SSH configuration is not a very sexy topic. However, it is again something that lies well within our control to help decrease risk within our environments.

Once configuration management has been achieved, we can standardize key locations and ensure unified version management, but more importantly, we can control access-related controls such as which sub-channels of the protocol may or may not be used, deny root access, restrict deprecated SSH versions and algorithm usage, as well as control login restrictions and log how frequently and from where keys are being used. These controls, when implemented properly, already provide us a good baseline of control in our environment and SSH usage.

Taking Control

SSH user keys are frequently being used for remote administrator access and application-to-application connections for our most critical infrastructure. It is a question of risk, compliance and resilience that ultimately directly impacts our brand reputations. It is important for enterprises to have visibility, understanding and continuous monitoring of key-based authentication that potentially can impact numerous applications and platforms.

There are things we can and can’t control in this life, and knowing the difference is critical when it comes to gaining control of our environments. An aspect we can change is the server side configuration of our SSH servers and the public key component of the authentication equation. It’s just about impossible to find and control all private keys, so set that goal aside and focus on the steps outlined above.

Matthew brings over 15 years of high technology sales, marketing and management experience to SSH Communications Security and drives strategy, key account sales, and evangelism. His expertise in strategically delivering technology solutions that anticipate the marketplace has helped the company become a market leader.

Prior to joining the company, Matthew served as a member of the executive management team of ADP Dealer Services Nordic and Automaster Oy, where he was responsible for international channel operations and manufacturer relations. In addition, he was responsible for key accounts including Mercedes Benz, General Motors, and Scania CV. Before this, Matthew played professional soccer in Germany and Finland.

Matthew holds a Bachelor of Arts degree in German from the University of South Carolina and an MBA from the Helsinki School of Economics and Business Administration.