Skip to main content
banner image
venafi logo

What Are the Most Common SSH Security Risks?

What Are the Most Common SSH Security Risks?

January 5, 2022 | Scott Carter

Although Secure Shell (SSH) is the most broadly used security protocol for remotely managing Unix/Linux, routers, firewalls, and other systems, most organizations have limited or no formal SSH policies in place. Many security practitioners and managers outside of the Unix teams have only a cursory knowledge of SSH—some may not be able to tell you whether SSH uses certificates or public keys, let alone how broadly it’s used or the risks it poses if not properly managed. When badly managed or improperly implemented, SSH machine identities can be the root of serious cybersecurity risks.

Here is a list of the top SSH security risks that you need to be aware of.

How well are your SSH machine identities secured? Find out now!
Unapproved SSH servers

You need to be particularly careful when activating an SSH server because these types of assets enable remote login. Attackers could abuse this facet in a poorly controlled SSH environment using free implementations like OpenSSH to surreptitiously enable SSH on critical assets. With SSH set up, attackers could then gain remote access to an asset and thereafter do whatever they want with it. If you have users and administrators enabling SSH server access on systems where it isn’t required, you’re expanding your attack surface because attackers will have a greater possibility of remotely gaining access to those systems.

Unpatched SSH software

For systems where SSH use is justified, if SSH server and client software isn’t kept up to date with fixes and updates, it can unintentionally expose the systems and data it’s designed to protect and make them vulnerable to compromise.

Vulnerable SSH configuration

Most SSH server and client implementations (such as OpenSSH) include a significant number of configuration parameters that impact operation and security. Most administrators choose secure defaults. However, a couple of these default configurations, such as port forwarding and the location of authorized key files, aren’t optimal for security. In addition, if your users and administrators arbitrarily change those configurations without considering the security implications, they can open those systems to broader attacks.

SSH port forwarding

Dating back to the days where encryption wasn’t available for all protocols, SSH features the ability to forward traffic sent to a local port on an SSH client. The traffic is forwarded through the encrypted SSH session to the SSH server or even beyond. If local port forwarding is enabled on an SSH client that’s been granted SSH access to a server on the other side of a firewall, an attacker may be able to use it to bypass firewalls.

Private key compromise

When you configure SSH for public key authentication, private keys enable access to accounts. If a private key gets compromised, an attacker can authenticate into the account(s) where the private key is trusted. SSH private keys can be compromised in the following ways:

  1. Careless users
    When administrators are authorized to use SSH public key authentication, they can be careless in their handling of their private keys by placing them in insecure locations, copying them to multiple computers, and not protecting them with strong passwords.

  2. Administrator turnover
    When public key authentication is used for automated processes, one or more administrators can be responsible for managing the private key for the process. Administrators can make copies of those private keys and, if they’re reassigned or terminated, can still use the key(s) to authenticate to the target servers.

  3. Weak keys
    Because many SSH keys haven’t been changed in years, smaller length keys may still be in use, making it possible for a sophisticated attacker to derive the value of the private key. In addition, we have seen bugs in cryptographic libraries that have resulted in weak, easily breakable keys being generated.
Privilege elevation

SSH is generally integrated with other components to enable privileged access—including operating system permissions, sudo (which allows one user to run a program as another user), and privileged access management (PAM) solutions. It can be difficult to centrally orchestrate the secure configuration of all these components to prevent cybercriminals from successfully elevating privileges during an attack. What’s even more challenging is when you have multiple individual administrators each making decisions on the implementation of SSH without any central oversight or review. Without this oversight, you face greater potential for privilege elevation, especially because attackers remotely accessing systems over SSH will have an encrypted session within which to hide their actions.

Rogue known host keys

If users or administrators who initially establish a connection from an SSH client to an SSH server don’t check the authenticity of the public key for that server, they may inadvertently accept an attacker’s public key and enable a man-in-the-middle attack.

Lateral movement

After attackers gain an initial entry into your network, their next goal is typically to get onto other systems, which is called lateral movement. When cybercriminals’ jump from system to system, they can easily pivot on your network by abusing persistent SSH trust relationships to their advantage. That’s especially the case if administrators don’t review those keys often or maintain strong oversight over them. When SSH machine identities fall into the wrong hands, this is very dangerous for your organization because SSH users and automated process are typically granted elevated privileges.

Circumventing security controls

While cybercriminals are busy moving laterally within your network, they could come across firewalls and other security technologies designed to block malicious network activity. Unfortunately, if you don’t properly control your SSH environment, attackers could bypass these safeguards by configuring SSH for port forwarding or other privileges. Doing so would allow the attackers to communicate with other systems that leverage authorized connections via firewalls and thereby find an alternate yet nonetheless “approved” route through the network.

Obscured and exfiltrated data

Attackers like to hide within the infrastructure by using readily available tools, like the SSH protocol, to redirect and exfiltrate data without being detected by traditional controls. SSH enables traffic redirects and allows its users to set up a listening port on a client and tunnel data through an encrypted channel to an exit server port or vice versa. As a result, encrypted SSH connections can also be abused by attackers to exfiltrate data without being detected.

How can you mitigate SSH machine identity risks?

Unlike other security tools, SSH machine identities generally aren’t centrally managed. Instead, SSH is most often managed by individual administrators for the servers they control. Consequently, most organizations don’t have a central view or one way of controlling the configuration of SSH or the access it provides. This lack of central oversight leaves network administrators to their own devices, resulting in mistakes and significant security risks.

The best solution is to integrate a centralized platform like Venafi SSH Protect, offering full visibility of all machine identities across your entire enterprise. Enforce SSH key policies, discover and remediate policy violations or compromises, and more from a single dashboard.

Get started with a free and confidential SSH risk assessment from Venafi!

Related Posts

Like this blog? We think you will love this.
Featured Blog

Using SSH Certificates Instead of SSH Keys

But many organizations are still unsure about the benefits of switching from SSH keys

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

Scott Carter
Scott Carter

Scott is Senior Manager for Content Marketing at Venafi. With over 20 years in cybersecurity marketing, his expertise leads him to help large organizations understand the risk to machine identities and why they should protect them

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

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