SSH Certificates
SSH Certificates and authentication for Cased
At Cased we follow the industry's best practices by defaulting to SSH Certificates. They are used and trusted by the biggest companies in the world, including Apple, Microsoft, Meta, Amazon, and others.
The general workflow of SSH key authentication is well known to developers:
- An SSH key pair is generated on a developer's computer
- They submit the public key to a server or an administrator for key approval and distribution
- The administrator approves and deploys the public key to the server
- Finally, the user can now SSH into the server.
While this is secure and effective, public key authentication has drawbacks:
- Keys never expire and users must manage a set of credentials with access to highly sensitive systems and data
- Developers and teams can share keys and passwords
- Onboarding developers is a slow and manual process
- Rekeying, or rolling keys, is a manual and labor intensive process for a team, so it's rarely done even if it is necessary.
- The key approval and distribution process is long and unnecessary, often involving additional software to manage the many public keys.
SSH certificate authentication eliminates the need for the private/public key pairs stored across files on developer machines and servers.
In order for a SSH certificate to get access to a particular server, it must be signed by a certificate authority (CA).
A certificate contains a public key, name, and metadata like permissions or an expiration date. Instead of verifying public/private key pairs, you configure clients and hosts to verify certificates using your CA's public key.
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.
The Cased app will automatically create and manage an offline CA instance for each customer organization.
Customers can then opt to use SSH certificate authentication instead of keys by 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 the commands that you need to run in order to configure a host to allow any member of your organization to log in.
New Cased Shell sessions will automatically generate short-lived certificates signed by this CA. Access control will be configured by the certificate of your identity provider - there is no need to worry about SSH key management or off-boarding and onboarding new employees.
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:cert-authority,principals="[email protected]" ecdsa-sha2-nistp256 AAAA...
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:cert-authority,principals="[email protected],[email protected]"
ecdsa-sha2-nistp256 AAAA...