We live in a world where the technology we use is constantly evolving and SSH is no exception. Since its founding in 1995, SSH has always had its issues. Switching from version one to version two of the protocol did help substantially in reducing initial SSH vulnerabilities, however the problem remains the same that SSH keys are easily abused when they are not properly controlled. And let’s face it, very few organizations have a handle on SSH key sprawl. With SSH keys being easily generated and spread throughout an environment, it is easy for them to get out of control quickly. And since they don’t expire, SSH keys continue to live on their hosts for a very long time.
In 2010, OpenSSH made its next evolution in the release of SSH certificates, and while having common attributes with X.509 certificates—like serial number, validity period and more—SSH certificates are very different from TLS certificates. They are designed to be as simple as possible and are used only for SSH authentication. Now fast forward to 2021 when the industry is beginning to adopt this evolution at a rapid pace for three core reasons: ephemeral credentials, improved security, and simplified management.
The biggest gripe with SSH keys has always been that they do not expire. While, in the past, you did not have to worry about an SSH-related outage due to expiry, admins did have to worry about where keys were and who they belonged too. Most admins are extremely hesitant to touch SSH keys as they are typically unaware of what the keys were being used for and who they may have belonged to…
Enter SSH certificates. With the industry acceptance of SSH certificates, one of their biggest benefits contributing to their success is that they do indeed expire. Custom validity periods can be configured on these certificates, so they are only valid for the specific time designated by the issuing certificate authority. This allows for SSH certificates to be requested in an on-demand fashion and passively expire at the end of their validity period. This simplifies the complex web of permissions by ensuring that new access would need to be granted only when a task needs to be completed.
Like standard SSH keys, SSH certificates can have source restrictions, command restrictions and option enforcement enabled while they are being used. Where SSH certificates change the game is that since they are digitally signed, they cannot be altered regardless of the level of permissions. These restrictions are all configured in the SSH CA template and would need to be changed within that context to get around the restrictions that have been set. Additionally, since they are short lived, SSH certificates are far less likely to be leveraged by external third parties since they will expire when the validity period is exceeded, leaving potential attackers out of luck with accessing internal infrastructure over time.
It’s no secret that managing SSH keys can be a nightmare. Even with a management platform to enforce policy and rotate keys, enterprise-wide management is still challenging for most organizations. For small keysets that involve one private key and a low number of authorized keys, the management process can be relatively simple, but when managing at scale for thousands of authorized keys in a keyset it becomes difficult. The SSH inventory needs to be 100% accurate and the hosts need to be online to make this massive change. Often times, some of those hosts are unreachable and the rotation may need to be finished manually on this small number of hosts. With SSH certificates, this process is simplified by trusting the public key of the issuing Certificate Authority and a set of principles (used as identities) that dictate who has access to request certificates from the CA. So, instead of having to rotate these large keysets, a new certificate can be issued once the previous one has exceeded the validity period set forth in the certificate template.
What to do next
Even with all the added benefits SSH certificates bring to the table, one common factor with SSH keys remains—these machine identities still need to be managed. Without having an enterprise-wide platform to enforce the SSH certificate policies that are set forth by the organization, many organizations will find themselves quickly in the same boat they were in with SSH keys. Having the visibility into how SSH certificates are being requested and the templates they are being generated from is a pivotal first step into the adoption of this SSH evolution. Like keys, this will allow enterprises to make intelligent choices on how to best manage certificates for their specific needs and enable them to quickly automate the process, making the process #fastsecure.
See how Venafi SSH Protect can help you streamline SSH certificate management.