The awareness of the importance of proper management of SSH user keys is growing, but confusion still abounds within organizations.
They put great emphasis on finding and controlling all the private keys in their environment. The idea behind this emphasis is that private keys are similar to passwords, so keys can be managed by the same principles.
There are several reasons why this is not the case. For starters, think of the private key as the key to your house and the public key as the lock to your door. 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.
One of these things is not like the other
It’s critical to understand that SSH user keys are not passwords. Significant differences exist between them that warrant us handling them differently. There are five key differences to consider:
- Passwords can’t be generated without oversight. SSH user keys often can.
- Passwords are related to user accounts. SSH user keys don’t have to be.
- Passwords usually expire on a certain date. SSH user keys don’t.
- Passwords grant access to the operating system level without additional restrictions. SSH user keys can control both access and privilege levels.
- Passwords are primarily used for interactive authentication. SSH user keys are most often used for machine-to-machine authentication.
Even if we could locate all the private keys and store them all in a secure central vault, problems remain. 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 the target server and drop in a new key pair, which would allow you now to bypass that architecture in the future. This is an all-too-common scenario.
Controlling the locks
What alternatives exist, then? 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 we provision a key pair. First, it is possible during the generation of an SSH user key pair to place what is known 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 was 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.
The second option is to put a command restriction on the public key. This 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.
Lastly, when it comes to SSH configuration management, there are numerous controls at our disposal. SSH configuration is not a very electrifying topic. However, it is again something that lies well within our control to help decrease risk within our environments.
Monitor What You Value
Key-based authentication can potentially impact numerous applications and platforms; this is why it is important for enterprises to have visibility, understanding and continuous monitoring of them. 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.
Getting a handle on our environments necessitates looking at which things we have control of. This includes the server side configuration of our SSH servers and the public key component of the authentication equation. The idea of finding and controlling all the private keys is a bit of a pipe dream, so emphasis should instead be placed on restricting access and managing public keys effectively.