⇠ Back to the blog
Cover for SSH properly with SSH certificates

SSH properly with SSH certificates

Christian Nguyen avatarWritten by Christian Nguyen

Introduction

In general, most companies use public key authentication for their SSH deployments. Public key authentication uses asymmetric cryptography via a public/private key generated for each user and each host to authenticate. The general workflow of SSH key authentication is as follows: an SSH key pair is generated by a computer, you submit the public key to a server or admin for key approval and distribution, an admin then approves and deploys the public key to the server, and finally the user can now SSH into the server. While this is mostly secure and effective, public key authentication has its drawbacks - keys never expire - meaning mistakes are fail-open, management of keys while you scale is challenging, and the key approval and distribution process is long and unnecessary. Asking users to upload private key material to Cased Shell is fraught with perceived and real risk. That's why we are following the best practices of the biggest tech companies in the world by offering SSH certificate authentication to provide users a safer, easier, and more efficient developer experience.

How SSH certificate authentication works

SSH certificates are digitally signed objects that have metadata like username/hostname, restrictions, end date, permissions, and more. In order for a SSH certificate to get access to a particular server, they must be signed by a certificate authority. A certificate authority (CA) is a company or organization that acts to validate the identities of entities and bind them to cryptographic keys through the issuance of certificates.

To authenticate, client and server now simply authenticate and exchange certificates instead of keys. When the certificate is validated by the CA, one gains temporary access to the server. It's that simple.

This solves the weaknesses inherent to public key authentication mentioned in the introduction. Certificates have an expiration date (fail-secure), and eliminate the key approval and distribution process.

SSH certificate authentication makes SSH more secure, easier to use, and easier to operate.

How Cased uses SSH certificates

The Cased app will automatically create and manage an offline CA instance for each customer organization. Customers can then choose to opt to use SSH certificate authentication instead of keys by simply going to settings, and checking the box that says "Enable Certificate Authentication".

Once enabled, you will receive an organization-wide CA public key, as well as commands that you can run in order to configure a host to allow any member of your organization to log in as any user, or to configure a host to allow any user of your org to login as a single user.

Now, Cased Shell sessions will automatically generate short-lived certificates signed by this CA. Access control will be configured by the certificate by your IdP - there is no need to worry about SSH key management or off-boarding and onboarding new employees.

If you're interested and want to learn more about Cased Shell, feel free to schedule a demo, read the documentation, or send us an email at team@cased.com.