If you are not careful, poor SSH practices can make your SSH machine identities become a security liability instead of a security asset. When this happens, protected assets and services may become more vulnerable to unauthorized access and misuse. After an SSH machine identity gets into the wrong hands, an attacker can use it to gain unauthorized access to mission-critical systems, move laterally from system to system, and circumvent security controls.
Let’s review the most overlooked SSH machine identity management practices that could increase your vulnerability to security threats and cyberattacks. Knowing the misbehavior that you’re up against can ensure your organization is steering clear of negative consequences.
1. Unknown or unmanaged SSH keys
Throughout the years, administrators in any organization come and go, and there often isn’t a formal process to clean up the SSH keys that they leave behind, or you can’t track where all of them may be. This lack of process leads to a problem when old administrators leave and new administrators come onboard—likely not knowing what the old keys left behind are used for. So, out of fear of causing an SSH-related outage, new administrators don’t remove old keys and instead generate new SSH machine identities—with the ssh-keygen command—to take care of their administrative tasks and build new keys into their own automated processes.
The result of this faulty process is an unmanaged tangle of SSH trust relationships that can leave you and your company vulnerable. If an SSH key is compromised and regular rotation isn’t enforced, your organization is at risk for repeated unauthorized access—indefinitely.
2. No usage restrictions
Because they have a simple file format, SSH keys can easily be copied or shared, making the automated connections they enable subject to compromise and misuse. Without implemented usage restrictions, it will be difficult to know who’s using your SSH keys and for what purpose.
3. Weak or vulnerable SSH keys
If you have the older SSHv1 present in your environment, you could potentially leave an open entry path for cybercriminals. Without visibility into your entire SSH environment, you won’t know how big of a problem this could be. Of course, administrators may stumble across SSHv1 keys or spot check servers, but without a management solution to alert you where these vulnerable keys are, you may be flying blind when it comes to this risk.
4. Excessive root access
If there’s any SSH usage at all in your enterprise, there’s a high probability that root access is being granted for no other reason than it makes things easier for administrative tasks. While some applications may require root access to function, the majority don’t. Root access makes it difficult to monitor who’s doing what because the activities logged during a session are simply logged as root and not as the individual behind the keys. In an ideal scenario, root access would be disabled, forcing individuals to use their own keys to access a host for privilege elevation.
5. Keys replicated on new machines
For years the use of golden images—a simple, easy process that gets machines created in a repeatable manner—has existed in enterprises. All too often, however, during this process, unique SSH keys aren’t created for each new machine coming online, leaving you with duplicate SSH keys for every device built off this golden image. This creates the potential for a man-in-the-middle attack should one of these duplicate keys become compromised.
Ideally, the golden image has no SSH keys built into it and has unique keys generated on being built or there’s an automated process in place to rotate the key immediately when the device is spun up. Without a solution for SSH machine identity management, administrators are left with no easy way to check for duplicate keys throughout the enterprise.
6. SSH policy not followed
Many organizations find it hard to define policies for SSH, let alone enforce them. As a result, even SSH policies that may be in place aren’t being followed throughout the enterprise. Some of this is due to keys that potentially predate the policy, while other instances represent a blatant disregard for the in-place policy. Regardless, policy non-compliance can leave administrators holding the bag if something were to happen with their SSH keys.
To learn more about best practices for SSH key management, download our SSH Machine Identity Management for Dummies Guide.