Use SSH Certificate Authority in Vault

This topic explains how SSH certificate authority in Vault provides an alternative to traditional SSH key discovery, management, and rotation for Vault accounts.

Traditional SSH Keys

With basic SSH keys, users have a public/private key pair. The endpoint system is configured to trust the public key, and then anyone with the private key is granted access.

In this scenario, Vault is storing the private key, and it gives the same private key to any user who uses the stored vault account, or requires creating, storing, and assigning a different private key for every user in the Vault and configuring the endpoint to trust a separate public key created by each of the private keys. Since the public and private keys are tied together, if any changes are made, the endpoints would have to be reconfigured to trust each new public key.

SSH Certificate Authority

An alternative to the single public/private key pair, and the sharing of the private key, is to configure the endpoints to trust a public key as a certificate authority. This means the endpoints will trust any certificate signed by the private key of the trusted certificate authority. New certificates are generated, but no changes on the endpoint have to be made as long as the certificates are signed by the private key of the certificate authority.

Benefits

Vault sends new certificates for each user and access request, and these certificates are all short-lived. Short-lived certificates are important because the TTL (time to live) means they are only valid through the expiry time. They cannot be used after, even if shared.

Using short-lived certificates greatly reduces the attack surface, as the certificates can essentially only be used once.

When using a certificate authority for SSH, you no longer have to manage a sprawling inventory of key pairs across all of your endpoints. Just add the public key of the certificate authority to each endpoint once and you're done.

Use SSH Certificate Authority Accounts

Create SSH Certificate Authority Accounts

SSH Certificate Authority accounts are stored in Vault as a type of generic account. SSH Certificate Authority accounts can be added only as shared accounts.

When adding an SSH Certificate Authority account, the admin can choose to have Vault generate the private key, or upload an existing private key.

If they choose to upload a key, they must provide the passphrase for the key, if there is one. The private key cannot be changed or retrieved once the account is created.

The account group, permissions, and Jump Item associations can be edited like any other generic account. SSH Certificate Authority accounts can get both the Inject and Inject and Checkout roles.

Inject SSH Certificate Authority Accounts

Using SSH Certificate Authority accounts in the Console works like regular SSH keys. For shell jump sessions, the credential shows up as an option in the credential dialog if the user has permission to inject the account and the account can be used for the Jump Item.

When the credential is used in this way, the TTL on the certificate is five hours. If the shell jump session is longer that five hours and requires an action that needs re-authentication (e.g. stop all shells and start again), then the action will fail.

Check out SSH Certificate Authority Accounts

SSH Certificate Authority accounts can be checked out with the same rules as generic username/password accounts. Users can be given permission to checkout the account, and API accounts with Vault permissions can check the account out.

When checking out, the user gets two pieces of information they need: the certificate and the private key. They need both pieces to use the credential. After check-out, the user has five minutes to use it for authentication.

Checking out the credential in the web and the desktop console result in the same style of dialog. A dialog shows the certificate and private key in single line text fields. Both fields allow the user to copy each value with a single click and paste them into files for use with their SSH tool. Users of the desktop client can also retrieve the credentials using the bt vault subcommand of the rep cli.

Since the credentials are uniquely generated for each check-out/injection, there is no need to check the credential back in.