Standing SSH Access to Just-in-Time Access Blueprint
This blueprint replaces standing SSH keys and shared bastion logins with just-in-time access: short-lived, identity-bound credentials or certificates granted on demand with MFA and approval. Every session is brokered and recorded, driving standing credentials toward zero.
What and Why
Standing SSH access means long-lived private keys spread across laptops, shared bastion accounts, root logins, and credentials that outlive the people who created them. A stolen key is a permanent backdoor, key rotation is rarely done, and nobody can say for certain who actually logged into a server or what they ran. Just-in-time (JIT) access flips the model: by default no one has access; engineers request access tied to their identity, it is granted for a short window with approval where needed, and it expires automatically. Every session is brokered and recorded.
The migration moves from persistent keys to ephemeral, identity-bound, audited access, a core piece of zero-trust operations and a strong control for incident response and compliance.
Phases
Assessment. Inventory every way humans reach servers today: distributed SSH keys, shared bastion accounts, root logins, service accounts used by people, and emergency credentials. Map who has access to what and how it is granted and revoked. Quantify the number of standing credentials, the headline metric this project drives toward zero, and identify the highest-risk targets to migrate first.
Design. Choose a JIT model. A strong option is short-lived SSH certificates: a certificate authority signs a certificate valid for minutes after the user authenticates with single sign-on and multi-factor authentication, and hosts are configured to trust the CA rather than individual keys. Alternatively, use an access broker or HashiCorp Vault's SSH secrets engine to issue ephemeral credentials on demand. Define approval workflows for sensitive targets and role-to-access mappings under least privilege.
Broker. Stand up the access broker or certificate authority integrated with the identity provider, so access requests authenticate via OIDC and phishing-resistant MFA (WebAuthn/FIDO2). Configure session recording and command logging on the broker or bastion, and set short certificate and credential lifetimes so access cannot linger.
Migration. Roll out per environment, non-production first. Replace static authorized_keys with certificate trust by configuring hosts to trust the CA, and route logins through the broker. Remove distributed private keys and disable shared accounts as each environment cuts over. Maintain and test a break-glass path throughout so an outage of the broker or IdP never leaves operators locked out.
Audit. Centralize session logs and access-grant records, alert on anomalous or out-of-hours access, and produce access reports for compliance. Run periodic access reviews; because access is JIT, the default state is no access, which dramatically shrinks the review burden and the standing attack surface.
Key Risks and Mitigations
- Access disruption. Removing keys too fast locks out operators mid-incident. Migrate per environment, run JIT alongside existing access briefly, communicate the new request flow, and provide support during cutover.
- Break-glass gaps. If the broker or IdP is down, engineers still need a way in. Maintain a tested, tightly controlled, heavily audited emergency path with separate credentials stored securely offline.
- Audit blind spots. Direct host access bypasses recording and defeats the purpose. Enforce that all access flows through the broker via network controls, disable direct key-based login on hosts, and alert on any direct login attempt.
Recommended Tooling
Vault's SSH secrets engine or an SSH certificate authority, an access broker or bastion with session recording and command logging, an OIDC identity provider with WebAuthn MFA (Keycloak, Auth0), and centralized log storage for audit. Network policy to force all access through the broker.
Success Metrics
Track the count of standing credentials (toward zero), MFA coverage on access, session audit coverage, and time to revoke access (effectively instant, since access expires on its own).
Prerequisites
An identity provider with MFA, the ability to configure host trust for certificates or run a broker, centralized logging, and a tested break-glass procedure in place before removing standing access.