Linux
Britive integrates with Linux servers through the Britive Access Broker, enabling just-in-time SSH access without maintaining standing credentials. Keys are generated at checkout and removed at checkin — no persistent access remains between sessions.
Access Patterns
The broker supports three SSH access patterns:
- Local — scripts run directly on the target host; suited for hosts where the broker is installed or has direct file access.
- Remote — the broker connects to the target host via SSH using a privileged key; suited for infrastructure the broker manages remotely (e.g. EC2 instances).
- Browser-based via Bridge — the broker provisions the key remotely but hands it to Britive Bridge instead of the user; the session opens in the browser through a recorded proxy, and no credential reaches the user.
All patterns support optional sudo grants and TRX-tagged keys for concurrent sessions.
The broker communicates outbound to Britive over HTTPS only — no inbound ports are required on the broker host.
In This Section
- Getting Started
Deploy the Britive Access Broker on a Linux host and register Linux servers as Resource Manager resources for JIT SSH access.
- SSH Access
Grant and revoke JIT SSH access to Linux servers using temporary keys — with optional sudo and TRX-tagged keys for concurrent sessions.
- Remote SSH Access
Use the Britive Access Broker to provision and revoke temporary SSH access on remote Linux servers — the broker holds a privileged key and manages user keys on target hosts.
- EC2 SSH Access (SSM)
Grant just-in-time SSH access to EC2 Linux instances via AWS Systems Manager — the broker injects an ephemeral SSH key at checkout and removes it at checkin. No inbound SSH or bastion required.
- Browser-Based SSH via Bridge
Open clientless, recorded SSH sessions to Linux servers through Britive Bridge — one-time ed25519 keys provisioned at checkout, removed at checkin, never shown to the user.