Best Practices for SSH Key Management

Best Practices for SSH Key Management: What Are Your SSH Security Risks?

In my last blog, I talked a bit about where SSH is used and provided an overview of the basic components of SSH and how they operate. As I discussed before, SSH is a powerful security tool, protecting privileged access to mission critical systems. However, when it is not properly managed, it can become a security liability instead of asset. My goal is to help you understand the underlying challenges of securing SSH. In this blog, I’ll summarize some of the risks related to SSH, so when we move on to talking about best practices in my next blog entry, you’ll know why they’re needed. While this blog provides a summary, I’ve included a link at the bottom of the post if you’re interested in downloading a detailed list of SSH vulnerabilities.

The diagram below provides a summary of SSH risks. As you can see, the risks span the SSH server and client, with most arising on the server side.

• Unapproved SSH Servers
  If you have users and administrators enabling SSH server (sshd) 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 the systems where SSH use is justified, if SSH server and client software is not kept up to date with fixes and updates, it can expose the systems and data it is designed to protect and make them vulnerable to compromise.
• Vulnerable SSH Configuration
  Most SSH server and client implementations (e.g., OpenSSH) include a significant number of configuration parameters which impact operation and security, including options for authentication, root access, port forwarding, file locations, etc. Fortunately, over the years, most SSH implementation developers have selected default configurations that are more secure. However, there are a couple of defaults, such as port forwarding and the location of authorized key files, that are not optimal. 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. The challenge is that this provides the ability for unapproved communications to traverse firewalls. If the user of an SSH client that has been granted SSH access to a server on the other side of a firewall is allowed to enable local port forwarding, they open the possibility that an attacker can gain access to systems and devices which might otherwise not be accessible. By exploiting port forwarding, an attacker may bypass firewalls that have been setup to limit access to the server’s network. In addition, attackers avoid detection because they are operating over an encrypted SSH connection.
• Private Key Compromise
  When you configure SSH for public key authentication, private keys then enable access to accounts. If a private key gets compromised, an attacker can authenticate into the account(s) where the private key is trusted. Here are some of the risks posed to SSH private keys:
  • Careless Users: When users are authorized to use SSH public key authentication, they can be careless in their handling of their private keys, either placing them in insecure locations, copying them to multiple computers, and not protecting them with strong passwords.
  • Administrator Turnover: When public key authentication is used for automated processes, one or more administrators for the process will be responsible for managing the process’ private key. Administrators can make copies of those private keys and, if they’re reassigned or terminated, can use the key(s) to authenticate to the target servers.
  • Weak Keys: Because many SSH keys have not been changed in years, smaller length keys (e.g., 512 or 768-bit keys) are still in use, making it possible for a sophisticated attacker may derive the value of the private key. In addition, there have been bugs in cryptographic libraries (e.g., Debian in 2006) that have resulted in weak, easily breakable keys being generated.
• Unauthorized SSH Access
  Because SSH provides remote access into systems, it is critical that access be tracked and controlled. Since many organizations don’t have centralized oversight and control of SSH, the risk of unauthorized access is increasing. Here are a few of these risks:
  • Untracked Trust Relationships: Just as with any access method, not keeping an inventory of where SSH keys are installed and the trust relationships they establish between systems and accounts is a recipe for unauthorized access. With administrators coming and going over time, many organizations have accumulated large numbers of SSH keys but do not have visibility into the access they provide.
  • Terminated Employees: If SSH users—whether employees or outside contractors—change roles or are terminated and their access to SSH servers is not properly updated or terminated, these individuals can have ongoing (yet unauthorized) access to mission critical systems.
  • Backdoor Keys: By default, most SSH implementations (e.g., OpenSSH) allow users to configure their own authorized key files (placing a public key in an account so they can access it using a private key). If organizations don’t keep an up to date inventory of authorized keys and regularly review it, users or even attackers may place authorized keys in unexpected places for future access. 
• Privilege Escalation
  SSH is generally integrated with other components to enable access (e.g., operating system permissions, sudo, PAM, identity management, etc.). It is difficult enough to centrally orchestrate the secure configuration of all these components to prevent an attacker from successfully escalating privileges during an attack. It’s even more challenging when you have multiple individual administrators each making decisions on the implementation of SSH without any central oversight or review. Without this oversight, you’ll face greater potential for privilege escalation, especially since attackers remotely accessing systems over SSH have an encrypted session within which to hide their actions.
• Rogue Known Host Keys
  If a user or administrator who initially establishes a connection from an SSH client to an SSH server does not check the authenticity of the public key for that server, they may accept an attacker’s public key and enable a manin-the-middle attack.
• Pivoting Risk
  Once attackers gain an initial entry into a network (either via phishing or some other means), their next goal is typically to get onto other systems. If not tightly controlled and managed, SSH can enabled that movement (pivoting) between systems because of the persistent trust relationships created with SSH keys. And SSHenabled pivoting can be the most damaging because SSH users and automated process are typically granted elevated privileges. Many organizations leave themselves open to SSH-based pivoting because they have no inventory of deployed SSH keys that enable persistent access between systems.

The above list is a summary of SSH risks that exist in traditional IT, as well as cloud environments. As you can see, although SSH is an important security asset, it can quickly turn into a liability if it isn’t carefully managed. In my next blog, I’ll provide a roadmap of best practices for securely managing SSH and mitigating these risks.