Four SSH Vulnerabilities You Should Not Ignore

The Secure Shell (SSH) protocol, developed in the mid-1990s, is widely used throughout traditional and virtual datacenter environments to enable secure remote access to Unix and Linux systems. You can think of the SSH key, which enables this remote access, as a “Swiss Army Knife” for IT teams, in that it helps administrators and developers authenticate to systems, build authentication into systems and applications and encrypt the resulting traffic between its users and systems. In the authentication process, these SSH keys often establish direct, privileged access to a variety of critical systems, effectively turning these cryptographic assets into privileged credentials. Yet when most people think about securing their privileged credentials, they typically only think of passwords – SSH keys rarely come to mind. As a result, these keys can easily fall into the wrong hands, and instead of protecting access to important assets, these keys can become “virtual skeleton keys,” providing attackers with privileged access to the organization’s most sensitive systems and data.

Four SSH vulnerabilities you should not ignore:

1. SSH Key Tracking Troubles. It’s not uncommon for a typical large enterprise with 10,000+ servers to have more than one million SSH keys – making it incredibly difficult to track them all. For example, organizations could lose track of SSH keys when development servers are migrated into production environments (without scrubbing development environment credentials), or when employees leave and the keys are never changed. The result? Unaccounted-for SSH keys can provide attackers with long-term privileged access to corporate resources. If attackers gain access to a key that is never revoked or rotated, the attackers could have a permanent network entry point.

2. When it Comes to SSH Keys, Sharing Isn’t Caring. For the sake of efficiency, SSH keys are often shared or replicated across a common group of employees or servers and infrastructure components. Though this approach may make IT teams’ jobs easier in the short-term, it significantly reduces security because it discourages key rotation and revocation. SSH key sharing is also dangerous because it reduces auditability and nonrepudiation.

3. Static SSH Keys, Because “Ain’t Nobody Got Time for Rotation!” It’s easy to see how rotating one million plus SSH keys would be a logistical nightmare. So, instead of taking on this large burden, many IT administrators and security professionals rarely change and re-distribute keys for fear that a critical component or employee may be forgotten (which could mean anything from a simple inconvenience for a single employee to a major company-wide system outage). This approach results in a surge of static SSH keys, opening the door for attackers to compromise an unchanged key, use it to move laterally through the enterprise, and gain permanent, unauthorized access to sensitive data and assets.

4. Embedded SSH Keys – The Ones No One Wants to Mess With. SSH keys are frequently embedded within applications or scripts. Administrators are often strongly discouraged from rotating them because of the level of coordination required to prevent outages. As a result, static SSH keys embedded in applications and scripts can lead to persistent backdoors for attackers.

SSH keys can present a tremendous opportunity for hackers to gain privileged access to networks, stay connected and move about freely. To learn about SSH key challenges and best practices for mitigating associated risks while improving your overall security posture, visit for a library of free resources on this topic.

SSH Key Graphic_V2 short