Skip to main content
banner image
venafi logo

Now Is the Time to Focus On Safe Remote SSH Access

Now Is the Time to Focus On Safe Remote SSH Access

protect remote ssh access
April 1, 2020 | Bart Lenaerts


SSH on the rise for remote access

Over the past weeks, remote access for employees has become the new standard and Secure Shell (SSH) is one of the most essential transports. Administrators use SSH to manage IT systems, developers use it to modify application settings and automation tools use it to orchestrate services. But has this increased usage of SSH also increased associated risks?


The concept of jump server

It is important that most critical SSH sessions should run outside VPN connections. Why you may ask? Because if the VPN fails, administrators will no longer have access to one of the most essential transports to administer VPN and they will be isolated from assets or applications. Now, to make SSH safe from the public internet, organizations often use a jump-server, proxy or simply said an intermediary host that shields their internal IT assets from the outside world. These “bastion” jump server technologies are offered in opensource as well as commercially formats. One of the most know is of course OpenSSH and this suite of secure networking utilities has been adopted by most Linux distributions as well Microsoft Windows 10.


What about SSH keys?

The jump server deployment model indeed shields traffic, but it also comes with some challenges. One of them is around implementation and usage of SSH keys. These seemingly small critters—in the form of a public private file—are often created by asset owners or developers and enable automated connections. Their purpose is to help the user to save time and provide security without too much dependencies on Identity and Access Systems. Now, when poorly managed keys inadvertently grow legs and fall in the wrong hands, bad guys may use them to get access to your critical assets. Now more than ever, SSH keys need to be managed and hygiene in their usage has essentially become mandatory.


Risk insights from our experts

Over the past year Venafi machine identity experts have executed dozens of SSH risk assessments. These stories can be very sobering. Here are some of the biggest challenges and risks that we uncovered:


  • Key Sprawl: Number of keys deployed is ten to fifty times the number that organizations estimate and no one knows why.
  • Love for Root keys: Administrators often give themselves root keys where they may not be needed.
  • Orphaned keys: Simply said, the public part of the key is still around even after the private one is gone. Yes, it may be on that laptop lost on the plane ride back from Las Vegas or could it also have been left on that USB backup drive forgotten in that coffee shop. The point is that if you don’t know where the private key parts are, others may use them to get access.
  • No concept of zones: Modern teams split their systems into different zones: development, test and production are most common. But what about the keys? Often, they have been deployed in abundance without this concept of zones. This may accidentally allow adversaries to pivot from environment to environment to find the most succulent customer data using a key from a developer, for example.


Common Practices

To defend against some of this bad new, here a set of simple best practices for SSH key usage and security. If you want more detailed info, you may wish to peruse a free download of NIST IR 7966.


  1. Own all keys between jump server and asset: One of the foremost practices is to have a solid inventory of all assets and their keys used from the jump host. These are your prime routes to and from, so they need to be inventoried and each key pair must be unique. Keys pointing to other assets outside the zone should be known and if their specific purpose can’t be determined, they should be removed.


  1. Monitor key deployment: Remote users will and should deploy new keys on the jump server. It is critical to monitor this at all times and get insights into when and where keys are generated and by whom. It may also be a good practice to regularly clean up keys from the remote users to the jump server, as their exposure there is very high. Also, any new key installed on the jump server from a suspicious location (i.e. a geo where company is not active) should be detected, removed and investigated.


  1. Eliminate unused or orphaned keys: Any key inside the “perimeter” not in use for a certain time period (let’s say 90 days) or keys where the private part is unknown should be removed. Full stop.


  1. Rotate: Rotation is part of a cybersecurity defense mechanism and reduces the risk that when a key part gets into the wrong hands, it may fall victim of nefarious use after the rotation. During these challenging times, SSH keys inside the perimeter should be rotated on a higher frequency. Weekly for “root” or highly privileged keys, monthly for all others looks acceptable practice


  1. Report and Communicate: Just as any part of the IT infrastructure, SSH usage should be reported on. Regularly. Building a set of metrics and sharing them with peers (Risk, InfoSec) helps create a mindset and perhaps an incentive to building out stronger SSH policies.

Where do I look for a solution?

The above guidelines can be intimidating, especially if you are new to the concept of SSH keys and other machine identities. For those interested to learn more, Venafi offers a solution called SSH Protect that can give you the visibility, intelligence and automation you need to protect your SSH keys. For more info, visit


Related posts


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

How Secure Shell (SSH) Keys Work

How it works SSH is a type of network protocol that creates a cryptographically secure

Read More
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

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

Bart Lenaerts
Bart Lenaerts
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