Using Teleport Just-in-Time Requests to Grant Temporary SSH Access Safely

The problem: standing privileged SSH keys

Many teams keep long‑lived SSH certificates or keys for engineers who need occasional admin access to production hosts. Those standing privileges increase the blast radius if a credential is leaked or a workstation is compromised.

Thesis: Teleport’s Just‑in‑Time (JIT) request workflow lets you grant short‑lived, role‑based access only when it is needed, with an auditable approval step.

How JIT requests work

When a user runs tsh request (or uses the Web UI), Teleport creates an access‑request object that must be approved by a designated reviewer. Upon approval, the auth service issues a short‑lived certificate whose lifetime is bounded by the request’s TTL and the cluster’s max_session_ttl. The certificate is automatically revoked after it expires, and every request, approval, and expiration event is written to the immutable audit log.

Prerequisites

• A Teleport cluster version ≥ 6.0 with the request plugin enabled in the auth service.
• A Teleport role that grants request permissions (e.g., allow request: roles: [*]).
• An approver user who has permission to view and act on access requests (typically a role with allow request: actions: [list, approve, deny]).
• The tsh client installed on the workstation where the request will be made.

Worked example: requesting temporary SSH admin access

1. Log in as the requester (needs a role that allows requesting).

   tsh login --proxy=teleport.example.com --user=alice

   Required permission: the user's Teleport role must include allow request.
2. Submit a JIT request for SSH access to host web‑01 with the admin role for one hour.

   tsh request ssh --user=root --roles=admin --ttl=1h web-01

   What happens: Teleport creates a request object; you see a request ID in the output (do not rely on a specific value).
3. Approver review – the approver logs in, opens the Teleport Web UI → Access Requests, locates the pending request, and clicks **Approve**. (Approvers can also use tctl request approve <request-id>.) Risk: If the approval step is bypassed via direct API calls, a certificate could be issued without oversight; ensure the request plugin is enabled and that only trusted roles have approve rights.
4. Verify the issued certificate – after approval, the requester can SSH to the host.

   tsh ssh root@web-01

   Check: Run tctl status (or tsh status) to see the active session and its remaining TTL; it should be close to the requested 1 hour.
5. Confirm audit logging – as an admin, list request‑related audit events.

   tctl audit list --request

   Look for entries: request submitted, approval, and session expiration. These entries are immutable and searchable by user, resource, and time.

Trade‑offs and limitations

• Standing request role required – the requester must already have a role that permits request. Misconfiguring that role (e.g., granting it to all users) can lead to privilege escalation because any user could then request any role they are allowed to ask for.
• TTL ceiling – the actual certificate lifetime cannot exceed the cluster’s max_session_ttl. If you need a longer window, an admin must raise that setting, which affects all sessions.
• Approval latency – the workflow adds a human step; for break‑glass scenarios you may want a separate emergency‑access process.

Actionable closing

If your team currently relies on standing SSH keys, start by creating a minimal requester role that only allows request for the specific admin roles you need. Test the flow in a staging cluster using the steps above, verify the audit log captures each event, and then roll out to production with clear documentation on who can approve and how long the typical TTL should be. This reduces standing privilege while keeping the approval process lightweight and auditable.