Vault SSH Signed Certificates: Short-Lived SSH Access (2026)

Vault can issue short-lived SSH certificates, allowing temporary, auditable access to your servers.

Let’s see it in action. Imagine you need to SSH into a server named webserver-01 for an urgent fix.

# First, authenticate to Vault
export VAULT_ADDR="http://127.0.0.1:8200"
vault login <your-auth-method>

# Request a certificate for the user 'deploy' on the 'webserver-01' host
vault write ssh-client-signer/sign/scp command='ssh deploy@webserver-01' public_key=@~/.ssh/id_rsa.pub

# Vault responds with a signed certificate
# Key: signed_key
# Value: -----BEGIN SSH2 CERTIFICATE-----
# ... (certificate data) ...
# -----END SSH2 CERTIFICATE-----

# Now, use the certificate to SSH
ssh -o "CertificateFile=/path/to/your/signed_key" deploy@webserver-01

This process bypasses the need for long-lived SSH keys or managing authorized_keys files on every server. Vault acts as the trusted Certificate Authority (CA).

The core problem Vault SSH solves is the inherent insecurity and operational overhead of managing static SSH credentials. Traditional methods involve:

Distributing SSH Public Keys: You need to add each user’s public key to the ~/.ssh/authorized_keys file on every server they need access to. This scales poorly and becomes a management nightmare.
Rotating Keys: If a key is compromised or an employee leaves, you have to meticulously remove their key from all servers.
Auditing: Tracking who accessed what and when relies on scattered auth.log files across your infrastructure.

Vault’s SSH Secrets Engine transforms this by acting as a dynamic SSH CA. Instead of distributing keys, you configure your servers to trust a Vault-generated CA. When a user needs access, they request a signed certificate from Vault, which is valid for a short, pre-defined duration (e.g., 1 hour).

Here’s how the system works internally:

Vault SSH Secrets Engine Configuration: You enable the ssh secrets engine at a specific path (e.g., ssh) and configure it with a signing key pair. This key pair is Vault’s identity as the SSH CA. You then register this CA public key with your target servers.
Server Trust: On each server that will accept Vault-signed certificates, you add Vault’s CA public key to the sshd_config file using the TrustedUserCAKeys directive. For example, in /etc/ssh/sshd_config:
```
TrustedUserCAKeys /etc/ssh/vault-ca.pub
```
You then restart the SSH daemon: sudo systemctl restart sshd.
Certificate Request: A user authenticates to Vault and requests a certificate. They provide their public key and specify the target host and username for which the certificate should be valid.
Certificate Signing: Vault uses its configured SSH CA private key to sign the user’s public key, creating a short-lived certificate. This certificate contains metadata like the principal (username) and validity period.
SSH Access: The user uses their private key to authenticate, but presents the signed certificate to the SSH server. The server verifies the certificate against the TrustedUserCAKeys file. If valid, access is granted.

The key levers you control are:

Signing Key Configuration: When enabling the ssh secrets engine, you can generate a new key pair or use an existing one. Vault will provide the public key to distribute to your servers.
```
vault secrets enable -path=ssh ssh
vault read ssh/config/ca
# This will output the public_key value you need to copy to your servers.
```

Role Definitions: You define roles within the ssh secrets engine that dictate which principals (usernames) can be signed for, allowed IP addresses, and the maximum TTL for certificates.

vault write ssh/roles/webservers \
    key_type=ca \
    default_user=ec2-user \
    allow_user_cert_principals=ec2-user,admin \
    ttl=30m \
    max_ttl=1h \
    cidr_list=10.0.0.0/16

Certificate Signing: The sign endpoint is used to generate certificates based on the defined roles.

vault write ssh-client-signer/sign/webservers \
    public_key=@~/.ssh/id_rsa.pub \
    cert_serial_number=12345

Time-To-Live (TTL): Crucially, you set the ttl and max_ttl for certificates. This ensures access is automatically revoked after a short period, minimizing the window of exposure if a certificate is leaked.

When you sign a certificate, Vault embeds the requested principal (the username on the target machine) and the validity period. The SSH server, trusting Vault’s CA, checks if the certificate’s principal matches the user attempting to log in and if the current time falls within the certificate’s validity window. If both are true, authentication succeeds without needing a password or a pre-existing key on the server for that user. This is incredibly powerful for ephemeral environments or just-in-time access.

The most surprising part for many is that ssh-keygen itself can generate the necessary key pairs for Vault’s CA and for users requesting certificates. You don’t need special Vault plugins for basic key generation; standard OpenSSH tools suffice for preparing the cryptographic material Vault will use.

The next step you’ll likely encounter is integrating this with your CI/CD pipelines for automated deployments, where you need temporary credentials to provision or update servers.

More Deep Dives in Vault