SSH Certificates

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, 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. We are following the best practices of the biggest tech companies in the world by offering SSH certificate authentication to provide users a better 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.
Authorizing access to specific hosts or usernames
​
In addition to including a digital signature that authenticates that an SSH connection has originated from a member of your Cased Organization, each certificate generated by your Organization’s CA also includes a list of Principals - or names - for which this certificate is valid, allowing you to authorize connections to some hosts or usernames from a specific set of users. Today, each certificate generated by a Cased CA includes the following principal names, formatted as emails for convenience and legibility:
Your full IDP username ([email protected])
The ID of the Shell instance from which the connection is being established (noreply+<shell_id>@cased.com)
The ID of your Cased Organization (noreply+<org_id>@cased.com)
To configure a user to only authorize connections from the user identified by your IDP platform as [email protected], you can change the principals portion of the ~/.ssh/authorized_keys file to the following:
1
cert-authority,principals="[email protected]" ecdsa-sha2-nistp256 AAAA...
Copied!
To additionally authorize connections from all users with access to a specific shell instance, add that Shell’s principal name to the principals line in your ~/.ssh/authorized_keys entry:
1
cert-authority,principals="[email protected],[email protected]" 
2
ecdsa-sha2-nistp256 AAAA...
Copied!
​

Web Shell - Previous

Host and container auto-detection

Next - Web Shell

Live SSH session sharing

Last modified 6mo ago

Copy link

Contents

Introduction

How SSH certificate authentication works

How Cased uses SSH certificates

Authorizing access to specific hosts or usernames