SSH Gatekeeper replaces long-lived authorized_keys with short-lived SSH certificates signed by a per-tenant Certificate Authority. Users don’t have standing access — they request access to a specific host, an approver signs off, HostAtlas issues a certificate valid for the requested TTL, and (optionally) the whole session is recorded.

You’ll find it in the sidebar under Security → SSH Gatekeeper.

What you see

The landing page has two panels:

• My requests — the last 50 access requests you’ve raised, with status (Pending, Approved, Denied, Expired, Revoked) and TTL remaining.
• Pending approvals — requests from other people in your tenant, if your role is Owner or Admin. Approve / Deny buttons are inline.

Each request opens a detail page showing the target server, requested SSH user, reason, source IP, TTL, approver, and every SSH session recorded against that certificate.

Two sub-views hang off the main page:

• My SSH keys — the public keys you’ve registered so HostAtlas can sign them into certificates.
• Recordings — every recorded session across the tenant (server, user, timestamp, duration), with playback.

Per server, an SSH Gatekeeper section on the server page shows the current config, recent requests against that host and its recent sessions.

What you can do

As a user

• Request access — pick a server, an SSH user (root, deploy, etc.), a TTL (1–240 minutes), an optional reason and an optional source-IP restriction.
• Register an SSH public key — Gatekeeper signs your key, not a shared one. Ed25519 and RSA are recognised automatically.
• Download the issued certificate as *-cert.pub for use from your terminal, or use the HostAtlas SSH Client which pulls it in for you.

As an approver (Owner / Admin)

• Approve a request — this triggers CA signing and unlocks the cert for download.
• Approve from email — one-click signed link, no login round-trip.
• Deny a request with a reason.
• Revoke an already-approved certificate before it expires.

Per-server config

• Enable Gatekeeper on the host — this queues an agent command that installs the tenant CA public key and updates sshd_config to trust it.
• Choose mode: self_service (approved instantly) or approval_required (default).
• Set default TTL, max TTL and default allowed SSH users.
• Toggle Record sessions (asciicast) and set retention days.
• Toggle Require reason and Require source IP.
• Disable Gatekeeper — the agent reverts sshd_config on next poll.

How it works

1. You submit a request against a server. Gatekeeper checks the per-server config: is the SSH user in the allowlist, is the TTL within the maximum, is a reason and source IP present if required.
2. If mode is approval_required, an approver has to click Approve (in-app or by signed email link). If mode is self_service, approval is automatic.
3. On approval, Gatekeeper signs the requester’s public key with the tenant CA, embedding the SSH user as a principal, the TTL as valid before, and (if set) a source-address restriction. The signed certificate is returned to the requester.
4. sshd on the target server trusts the tenant CA (installed at enable time), so it accepts any correctly-signed cert without touching authorized_keys.
5. If Record sessions is on, the agent wraps the shell in asciinema-format recording and uploads it to HostAtlas at session end.

Certificates cannot be reissued after they expire — the requester raises a new request. An approver can Revoke early; revocation writes to the CRL that the agent picks up on the next poll.

Every step (requested, approved, denied, revoked, cert-downloaded, enabled, disabled) is written to the tenant Audit Log under the ssh_gatekeeper.* action prefix.

Tip

CLI users can drive the whole flow with hostatlas ssh request, hostatlas ssh status and hostatlas ssh connect — the CLI polls until approval, writes the cert to ~/.ssh/, and launches ssh for you.

Recordings

Recorded sessions are stored as asciicast v2 (a plain-text JSON stream, replayable in the browser and downloadable). They inherit the retention configured per server. Deleting a recording is logged.

Related

• Audit Log — every Gatekeeper event lands here under ssh_gatekeeper.*.
• Policy Engine — enforce rules such as “all production servers must have Gatekeeper enabled”.
• Firewall — pair Gatekeeper (who can SSH) with UFW (which ports are open at all).