Skip to main content
banner image
venafi logo

Best Practices for Securing SSH: What Are Your SSH Security Risks?

Best Practices for Securing SSH: What Are Your SSH Security Risks?

ssh security risks
September 28, 2017 | Paul Turner

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.

 

How are cybercriminals taking advantage of real TLS/SSL certificates on fake sites? Find out.

 

 

SSH_Security_Risks-2.jpg

  • 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.

 

Is your SSH security better than that of your peers? Read our eBook.

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

NIST TLS Infosec Guidelines

New NIST TLS Management Guidelines for InfoSec [Expert Advice]

NIST Guidelines TLS

What Executives Need to Know about New NIST Guidelines for TLS Management

Best Practices for Securing SSH: Defining SSH Policies

About the author

Paul Turner
Paul Turner

Paul Turner writes for Venafi's blog and is an expert in machine identity protection.

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
Chat