Privileged Access with Short-Lived Certificates

The weakest link in server access is usually not an attacker — it’s the keys that have been alive for years. Shared SSH keys for privileged accounts blur the question of who accessed what and when; once a key leaks, narrowing the blast radius becomes painful. Designing access around short-lived certificates may not eliminate the bastion-host pattern entirely, but it makes access far more controllable along three axes: time, identity, and intent.

Why is the permanent key model problematic?

Using permanent keys looks practical for small teams. At enterprise scale, though, it produces these problems:

• Time-to-revoke for privileged access stretches out.
• Keys are easy to share or copy.
• The justification for access becomes disconnected from the technical access itself.
• After an incident, it can be unclear which session belonged to whom.

Especially in environments with many vendors, ops teams, or temporary access needs, this model isn’t sustainable.

How does the short-lived certificate model work?

The core flow is simple:

1. The user authenticates against the central identity system.
2. The privileged access request is evaluated through policy.
3. After approval, an SSH certificate valid for a few minutes or hours is issued.
4. The server only accepts certificates signed by a trusted CA.

In this way, access is granted via a real-time authorization decision rather than static keys distributed to devices.

What components does this model require?

The full enterprise solution depends on product choices, but the component logic is similar:

• Central identity provider
• Policy or access-approval layer
• SSH CA or certificate-signing service
• CA trust chain on target servers
• Session and command audit visibility

With this structure, when a user account is disabled, no new certificate is issued — and access effectively shuts off.

Host production-*
  User ops
  CertificateFile ~/.ssh/id_ed25519-cert.pub
  IdentityFile ~/.ssh/id_ed25519

What changes on the server side?

Instead of storing public keys per user on every host, you define a trusted CA. User changes are then managed in the central signing chain rather than host by host. Operationally — especially across hundreds of Linux servers — this is a serious simplification.

Major advantages of this model:

• Reduces authorized_keys clutter on hosts.
• Wires temporary-access requests into automation.
• Makes the chain from identity to access decision auditable.
• Bounds privileged access by duration and role.

What’s the most common mistake during the transition?

Some teams switch to the short-lived certificate model but leave the old permanent keys in place “just in case.” The system looks secure, but in practice two parallel access models live on. The migration plan must explicitly state which host group will accept only certificates and from which date.

Where should you start?

The best initial scope is high-risk access where the user count is bounded:

• Production Linux administration accounts
• Network-device management access
• Jump accounts in ERP or batch infrastructure

Once these groups succeed, the model can be extended to other management planes.

Conclusion

Designing privileged access around short-lived certificates breaks the “distribute the SSH key and forget it” habit. Granting privileged access in the context of identity, duration, and approval delivers auditability for security teams and a more controlled lifecycle for operations teams. If you want security to be a permanent part of large-scale infrastructure, granting access through a temporary trust decision — not a permanent key — is the right path.