Teleport JIT SSH: Short-Lived Certificates Instead of Standing Keys

Standing SSH keys in production are a security liability. When a key is added to a remote authorized_keys file, it remains valid until someone manually removes it. This creates a window where credential theft, laptop compromise, or incomplete offboarding allows lateral movement long after the necessary work is finished.

The solution is a shift to Just-in-Time (JIT) access. Teleport solves this by stopping the distribution of static keys and instead issuing short-lived certificates only on demand. These certificates are bound by identity validation, optional approval workflows, and a strict Time-to-Live (TTL) that expires automatically.

What JIT changes in the SSH flow

With traditional SSH, authentication is key-based and persistent. With Teleport JIT, authentication is certificate-based and ephemeral.

A user authenticates to the Teleport auth server using tsh, typically backed by an identity provider and multi-factor authentication (MFA). The auth server checks the user's role. If the role requires JIT, the connection is not granted immediately; Teleport can require an explicit approval from a designated reviewer.

Once approved, the auth server signs a user certificate with a configurable TTL—for example, 15 to 20 minutes. The client uses this certificate for the SSH session. When the TTL expires or the session becomes idle, access ends without manual revocation. No private key stays on the target host.

• RBAC: Role-based access control that defines who can access what.
• TTL: Time-to-live, the maximum lifetime of the certificate.
• MFA: Multi-factor authentication to reduce risk from stolen passwords.

Role and configuration

JIT behavior is driven by the role rather than a global toggle. A minimal role that enables JIT for SSH can look like this:

kind: role
metadata:
  name: db-jit-access
spec:
  allow:
    logins: ["admin"]
    node_labels:
      env: ["prod"]
    jit: true
  deny:
    # optional constraints

Assign this role to a user via the Teleport Web UI or tctl. Approvers must be a separate group with permission to approve requests. Operators should also set auth service limits such as idle_timeout and max_session_ttl so a certificate cannot be unintentionally extended by a long-running session.

Version note: JIT approval workflows require Teleport 10+. The jit module configuration referenced in documentation is for Teleport 13+.

Worked example: request, approve, connect

The flow below shows the commands a user runs and where approvals happen. Replace placeholders with your proxy address and node name.

On the user workstation, authenticate to Teleport:

tsh login --proxy=teleport.example.com --auth=local

Run this as the user who needs access. It prompts for MFA and stores short-lived credentials in ~/.tsh. Required permission is the ability to log in to the proxy.

When the user attempts a connection that requires JIT, Teleport creates a request in the Web UI:

tsh ssh admin@db01 --proxy=teleport.example.com

The auth server validates identity and RBAC, then notifies approvers. An approver opens the Teleport Web UI, reviews the request, and approves or denies it. After approval, the auth server signs a certificate with the role's TTL and the client establishes the SSH session.

The session ends automatically when the certificate expires. Operators can review the lifecycle in Teleport audit events: request created, approved, session start, and session.end.

Trade-offs and limits

JIT adds a human step. The approval round-trip adds latency, which can be disruptive for urgent incidents. Operators must maintain approver groups and ensure coverage across shifts.

Misconfigured TTLs can either block legitimate work or leave windows of standing access. JIT also requires an identity provider that supports MFA; without it, stolen passwords could still initiate a request. Operators must maintain approver groups and audit logs, adding operational overhead.

Getting started and verification

To try JIT, enable the jit module in Teleport 13+, define a role with allow: { jit: true }, test with tsh login and tsh ssh, then review the audit events in the Teleport UI to see the request‑approval‑session lifecycle.

Verify the certificate presented to the SSH client has a short validity period:

ssh-keygen -L -f ~/.tsh/keys/.pub

Confirm no long‑lived keys are stored in ~/.ssh. Check auth logs for session.end events to ensure sessions terminate at the configured TTL.