Skip to main content
banner image
venafi logo

6 Dangerous SSH Key Management Practices You Should Avoid

6 Dangerous SSH Key Management Practices You Should Avoid

September 8, 2021 | Alexa Hernandez

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.

Get a FREE & Confidential SSH Risk Assessment Today!
  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. 

Related Posts

  • Everything You Need to Know About SSH Machine Identities
  • 5 SSH Machine Identity Risks You Must Consider
  • Why is SSH Machine Identity Management So Challenging?
Like this blog? We think you will love this.
Featured Blog

All About SSH Key Management and SSH Machine Identities

SSH is a secure way to initiate remote computer access and en

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

Subscribe Now

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Alexa Hernandez
Alexa Hernandez

Alexa is the Web Marketing Specialist at Venafi.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more