Privileged Access for SSH

Twingate Privileged Access for SSH

Twingate Privileged Access for SSH adds zero trust access controls to SSH connections. It extends Twingate’s private networking to cover individual SSH sessions, enforcing least-privileged access at the application layer without changing how your developers work.

Key benefits

• No SSH keys on devices. Twingate authenticates users and forwards their identity to the Gateway, which requests a short-lived certificate per connection. No SSH keys to distribute, and revoking a user’s Twingate access removes SSH access instantly.
• Full session auditing. All SSH activity is logged and attributed to specific identities. Session recordings are stored in asciicast v2 format on your own infrastructure.
• No workflow changes. Users connect using standard ssh with no custom CLIs required.

How it works

Twingate Privileged Access for SSH introduces a Gateway, a Layer 7 reverse proxy deployed within your environment that handles identity propagation and session recording for SSH connections.

When a user initiates an SSH connection, Twingate authenticates the user via their identity provider and forwards their identity to the Gateway. The Gateway then authenticates to the target SSH server using a certificate issued by an SSH Certificate Authority (CA). No SSH keys are distributed to users, and no bastion host is needed.

The Twingate Client can sync the SSH CA’s public key to ~/.ssh/known_hosts, so when the Gateway presents its host certificate, the client trusts it automatically. No Trust On First Use (TOFU) prompts.

Components

Gateway

The Twingate Gateway is a standalone Layer 7 reverse proxy that:

• Terminates the inbound SSH session from the SSH client
• Authenticates to the target SSH server using certificate-based authentication
• Records the full session and exports it to stderr in asciicast v2 format

The Gateway is deployed into your environment (Kubernetes cluster or VM) and is associated with a Remote Network in Twingate. A single Gateway can serve multiple SSH Resources within the same Remote Network.

Certificate Authorities

Two Certificate Authority (CA) types are used with the Gateway:

• X.509 CA: Secures the connection between the Twingate Client and the Gateway. Required for every Gateway.
• SSH CA: Issues short-lived user certificates for authenticating to target servers, and host certificates for verifying the Gateway identity. Required for any SSH Resource associated with the Gateway.

CAs are managed under Settings > Certificate Authorities in the Admin Console. You can create multiple CAs of each type and reuse them across Gateways.

The Gateway supports two modes for signing SSH certificates:

• Local SSH CA: The Gateway holds the CA private key and signs certificates directly. Suitable for getting started and simpler deployments.
• HashiCorp Vault: The Gateway uses Vault’s SSH secrets engine to sign certificates. Recommended for production: keeps private keys off-disk and provides audit logging for all certificate operations.

Support for additional certificate authorities is coming soon.

Supported SSH features

Supported:

• Interactive shell
• Remote command execution
• File transfer (sftp, rsync)
• TCP/IP port forwarding

Not supported:

• X11 forwarding

User configuration

The Gateway presents an SSH host certificate issued by the SSH CA. To avoid Trust On First Use (TOFU) prompts, users can sync the SSH CA’s public key to ~/.ssh/known_hosts.

To sync the SSH configuration:

• Open the Twingate Client.
• Under More, select SSH Server Configuration Auto-Sync. This syncs the SSH CA’s public key to ~/.ssh/known_hosts and keeps it updated automatically.

Client version

Privileged Access for SSH is available on macOS, Windows, and Linux. Mobile clients (Android and iOS) are not supported. Minimum Client versions:

• macOS: 2026.85
• Windows: 2026.90
• Linux: 2025.342

Session recording

All SSH sessions are automatically recorded. Logs are exported to stderr on the Gateway in asciicast v2 format and are stored entirely within your infrastructure. They are never uploaded to Twingate.

Session recordings capture terminal I/O for interactive shell sessions and command output. The Gateway also logs SSH events such as channel open and close.

Logs can be forwarded to a SIEM or object storage for retention and compliance. To visualize a session recording, you can use the Twingate session player at twingate.com/sessionplayer. File transfer and port forwarding data is not recorded.

Frequently asked questions

Do I need to remove existing SSH keys from my servers?

No, the Gateway adds the SSH CA’s public key as a trusted CA; existing authorized_keys entries are unaffected. You can migrate to Twingate-only access at your own pace.

Can I use this with non-Linux servers?

Yes, Windows Server with OpenSSH installed is supported. The same setup process applies.

Where are session logs stored?

Session logs are stored entirely on your own infrastructure. Twingate does not have access to session content. Logs are written to stderr on the Gateway, and you are responsible for forwarding and retaining them.

Does this replace my bastion host?

Yes, the Gateway provides equivalent functionality while adding identity propagation, session recording, and zero trust access controls.

Getting started

See Installing Privileged Access for SSH for prerequisites and deployment options.

Guides

• Remote development with Twingate SSH — Set up VS Code, JetBrains, and Cursor for remote development

Join us in the community subreddit to share your setup experience or ask questions.