3 Reasons to use SSH Certificates instead of SSH Keys – SecAdvent Day 22

SSH Keys are easy and the technology is sound. That much we can all agree on. Where the disagreement on this subject starts is around the safety and management of said keys. There is a lot to say about best practices around handling of SSH Keys within an organization, and I hear your arguments.

However, SSH Certificates are simply the better way to go.

Before going into why to use SSH Certificates, here are some reasons why SSH Keys management is  cumbersome and difficult.

This post originated as a talk in the DevSecCon track at Community Summit TLV.

Issues with SSH keys

Why are SSH Keys an issue? From an Ops perspective, there is a need to provision keys whenever a new employee begins working, or deprovision keys when someone leaves the organization.

SSH Keys can also be lost. When a regulatory issue may come up, you’ll need to audit and clean up permissions, so that you’ll need to re-pair between the public keys and their corresponding private key owner. More than that, it’s hard to audit the system for shared team SSH Keys and figure out who owns them. And finally, a key can definitely be stolen in a number of ways, given the fact that it is just lying there, on your laptop, leaving you open to attack.

All of these point to SSH Keys being a hassle and time waste for any organization, especially as it scales. That’s why it’s time to move to SSH Certificates.

What are SSH certificates?

SSH Certificates, put simply, are files with specific information, such as:

• Who wants to access the target host  (username, password)
• Who is the Certificate Authority (CA) that signed it, and
• How long should the certificate be valid for (the shorter-lived the better)

For the more advanced side, certificates also allow the certificate issuer to determine what local users (for example: root, ubuntu) the certificate holder can use to log in. Furthermore, you can use SSH Certificates in order to restrict certain commands.

3 great reasons you should start using SSH certificates

Here are just three reasons why it’s better to use certificates rather than keys:

1. There is no need to provision or deprovision them.
2. Certificates are actually super simple to implement with just one line of code (see below).
3. They are short-lived and self-destructive, so they expire automatically.

WHEN YOU SCALE, YOU DON’T WANT THE COMPLEXITY OF MANAGING ALL YOUR KEYS, DEALING WITH REGULATORY ISSUES & POTENTIALLY BEING OPEN TO SECURITY BREACHES BECAUSE USERS AREN’T BEING CAREFUL WITH THEIR KEYS.

If SSH certificates are so great, why does no one use them?

Well that’s a great question. I’d suggest the following reasons:

Bad PR: There hasn’t seemed to be enough of a push to get organizations to use certificates. Although Facebook, Uber, Netflix, Lyft and others have embraced SSH Certificates, the good PR is still yet to come.

Requires PKI knowledge: There is some PKI knowledge needed to make this work. PKI is basically the technology used to authenticate users and machines using a cryptographic key which then serves as the identity for the entity (more on that here).

Requires infrastructure setup: SSH Certificates are not as difficult as you think, but you do need to do some configuration first.

Prerequisites for getting started with SSH certificates

1. Set up an internal Certificate Authority. You can use ‘ssh-keygen’ for sandbox purposes. WARNING: You need to secure the CA private key either with a KMS or via some other method.
2. Configure your target host to trust the CA using its public key (with just one line of code, as mentioned).

THE FLOW: HOW THE SSH CERTIFICATE LOGIN PROCESS WORKS

SSH Certificate login is really simple:

1. A user asks for a certificate from the CA that was previously created.
2. The CA signs the request, creates the certificate, and sends it back to the user.
3. Finally, the certificate is provided by the user to the target host via SSH which validates the certificate with the CA public key which was configured earlier.

TAKING IT TO PRODUCTION

In this article, I gave you the basics which are really meant for using in a testing environment to show how it works. When thinking of an enterprise-grade solution, you’ll need to make sure your solution also includes the following:

• Who’s allowed to issue certificates?
• Authenticating via Okta, G-suite, Azure-AD
• How to protect your CA private key?
• Recording the SSH session for Audit & Compliance

CONCLUSION

Using SSH Keys can seem like the easy way out. We all know how to use them and we all do use them. When you scale, you don’t want the complexity of managing all your keys, dealing with regulatory issues, and potentially being open to security breaches because users aren’t being careful with their keys. It’s timely, risky and costly, and no fun.

While I showed the basics of using an internal CA solution for playground purposes, it is important to note that creating a production-grade solution for SSH Certificate management requires more thought and functionality. But once you implement SSH Certificates, you will have simplified access management for your organization and made your CISO a little bit happier.

NEED AN ENTERPRISE-GRADE SSH CERTIFICATE SOLUTION? CHECK OUT AKEYLESS VAULT.