Just-in-time access

How it works

Requests and grants live on your vault server. Any member can ask for access to a host, giving a reason, an optional ticket reference and a duration. An admin approves or denies it. An approved request is the grant: it starts the moment it is approved and lasts the requested number of minutes, never more than 8 hours. After that it simply lapses. An admin can also revoke it early.

Where a grant is checked decides how strong it is. There are three places:

What you need

• A Self Hosting Vault set up on every device that requests or approves. Without one, a host that requires JIT cannot connect at all. MangoSSH explains which host or policy asked for JIT and why it is blocked.
• At least one admin to approve. Only vault admins see the queue.
• For approval MFA: MFA_MASTER_KEY set on the vault server.

Require JIT on a host

1. Open the SSH host with Edit and go to the Access tab.

2. Under Just-In-Time access, turn on Prompt for Just-In-Time approval before connecting, then save.

To cover many hosts at once, use a policy with the Require Just-In-Time approval rule, scoped to a group, a tag or the whole fleet. A mandatory policy locks the switch on each host it covers. If a JIT policy exists but this device has no vault server, the Policies page warns that every host it covers is blocked.

The host switch and the policy rule apply to SSH hosts. For RDP and VNC, broker the host and turn on the vault-wide switch described below.

Request access

When you connect to a host that needs a grant and you do not hold one, the Request Access dialog opens instead.

1. Fill in Reason (shown to the approver), for example “investigating a production alert”.

2. Fill in Ticket / change reference, for example INC-4471. It is marked (required) when your vault demands one.

3. Set Duration (minutes). The default is 60 and the maximum is 480.

4. Click Request Access. The dialog shows “Waiting for approval…” and checks every few seconds. When an admin approves, it connects on its own. If they deny, you see their note.

Cancel only stops waiting. The request stays pending on the server, and if it is approved later, your next connect goes straight through.

Approve, deny and revoke

Admins have two places to work from. Both show the same data.

• Settings → Self Hosting Vault, in the Just-In-Time access requests section: Approve or Deny under Pending, and Revoke under Active grants.
• The PAM Dashboard (PAM Dashboard in the Dashboard's side rail): Pending requests lists each request with its reason, ticket reference, requesting device and requested minutes. Active escalations lists grants in force with the time left.

Requests identify the device that asked, by its key, not a person's name. The host shows by name when your device also has that host; otherwise you see the requester's host id.

Approving grants the duration that was requested, starting now. Revoking ends the grant at once, so the device can get no new connection, ticket or certificate for that host. What happens to a session that is already open:

• Direct SSH: it stays connected. JIT is checked at connect time only.
• Brokered SSH: revoking from Settings → Self Hosting Vault also asks the relay to end that device's brokered SSH sessions on the host, if a relay is set on your device. Revoking from the PAM Dashboard ends the grant only.
• Anything brokered that is still running is closed by the relay at the grant's original end time, which the ticket carried. The person sees “the access grant for this host has ended — session closed”.

To hear about new requests without watching the dashboard, turn on Access request waiting in the alert settings. MangoSSH checks about once a minute while it runs. See Audit, recording and alerts.

Require a ticket reference

Turn on Require a ticket reference on every access request in the PAM Dashboard under Pending requests → Approval security, or on the Policies page under Global. The vault server then rejects any request without one. The reference (up to 128 characters) is stored with the request, separately from the free-text reason, and approvers see it as its own tag. That separation is what lets a compliance review match each grant to a change or incident record.

Require a code to approve

Approving is the one privileged step in this flow. With approval MFA on, a borrowed or stolen admin device cannot approve anything on its own.

1. Each approver enrols on their own device. In the PAM Dashboard, open Pending requests → Approval security and click Set up authenticator. Add the secret it shows to your authenticator app. It is shown only once.

2. Enter the code your app shows to confirm. The enrolment counts only after this.

3. Turn on Require a one-time code to approve access. You must be enrolled first, so it cannot lock you out. If other admins have no authenticator yet, MangoSSH tells you how many and asks before it continues, because they will not be able to approve until they enrol.

From then on every Approve asks for the current code. A code cannot be used twice. Nobody, an admin included, can enrol an authenticator for someone else. Remove authenticator asks for a current code too.

Require JIT for brokered and shared access

Turn on Require an approved grant for brokered and shared access under Approval security (or, on the Policies page, Require a JIT grant for brokered and shared access). The vault server then:

• issues no PAM Broker ticket and no browser link to a non-admin who does not hold an active grant for that host;
• limits any ticket or link it does issue to the end of the grant, and the relay ends the session then;
• exempts admins, since they approve the grants.

This applies to SSH, RDP and VNC brokered hosts alike, and to links a member shares: a link can never outlast the grant it was shared under. MangoSSH shows the Request Access dialog before a brokered connect, so people are not left with a bare refusal.

JIT for SSH certificates

If you issue short-lived SSH certificates from the vault's CA, tick needs a grant on a role in the CA policy (Vault Dashboard → Certificates). The server then issues that role no certificate without an approved grant for the host, and caps the certificate's lifetime at the grant's end. A revoked grant stops working within one certificate lifetime.

Troubleshooting