HashiCorp Vault SSH: Short-Lived Certificates Replace Static Keys at Scale

Static SSH keys don’t expire. That’s the core problem — and it’s the reason that at enterprise scale, SSH key sprawl becomes a persistent security liability rather than a manageable credential type.

Context

SSH key authentication has been a production operations standard for decades, but the model has structural weaknesses that worsen with scale. Keys persist indefinitely unless explicitly revoked; revocation requires locating every copy on every host; inventory is manual and often incomplete; and compromise of a long-lived key provides durable access until discovered and rotated. HashiCorp Vault’s SSH Secrets Engine addresses this through a certificate authority model: rather than managing key pairs, Vault issues short-lived SSH certificates that expire automatically, anchored to identity provider authentication and enforced through role-based access policies.

The Detail

The architecture converts Vault into an internal SSH Certificate Authority. When a user or service needs SSH access, the workflow begins with authentication to an identity provider — not to Vault directly. Once authenticated, the public SSH key is submitted to Vault for signing. Vault returns a signed certificate with a configurable TTL (30 minutes in the reference implementation) rather than granting standing access. The target host validates the certificate against the CA’s public key, which is distributed to hosts in advance and requires no ongoing Vault connectivity. The Vault CA private key never leaves Vault.

This design resolves four structural risks that static key management cannot address. Private key compromise under the certificate model results in temporary exposure bounded by the TTL, not persistent access. Key rotation becomes automatic — certificates expire without revocation action required. Unauthorized access risk is reduced through the identity provider requirement on every signing request, enabling MFA enforcement at the authentication layer. And multi-cloud scalability is addressed because hosts require only the CA public certificate, not direct network paths to Vault, making the model viable across hybrid and cloud environments where network topology is variable.

Role-based access control is enforced through Vault policies mapped to principals. The reference configuration demonstrates three role levels — administrator, team-a, and team-b — each with distinct AuthorizedPrincipalsFile entries that restrict which principals a signed certificate can assert. A team-a certificate cannot escalate to administrator access even with a valid Vault authentication, because the signed principal is embedded in the certificate at issuance. This is a materially different posture from SSH key authorization, where a compromised key carries whatever permissions its authorized_keys entry granted at initial setup. Combined with the dynamic credential patterns emerging across infrastructure tooling, Vault’s SSH approach fits a broader identity-first access model where no credential is long-lived by design.

The audit trail is a secondary benefit that matters operationally. Every certificate signing request goes through Vault, which logs the identity, the role, the principals requested, and the timestamp. That audit path is absent in traditional SSH key management, where key usage logging depends on host-level sshd configuration — inconsistent and often incomplete across heterogeneous infrastructure.

Source: HashiCorp

Content created with AI assistance and reviewed for accuracy.