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 beyond the initial network connection to cover individual SSH sessions, so you can enforce least-privileged access at the application layer without changing how your developers work.

SSH servers stay hidden from the public internet using Twingate’s existing architecture. Access policies are defined using identity, device posture, and other contextual signals from a single policy engine that covers network, SSH, and Kubernetes access.

Key benefits

• Identity propagation. Twingate passes user identity through to your SSH servers using certificate-based authentication, so users don’t need to manage SSH keys or passwords on their local machines.
• No workflow changes. Users SSH into servers using their existing tools (OpenSSH on macOS and Linux, PuTTY on Windows, Termius on mobile) with no custom CLIs required.
• No SSH keys on devices. No SSH keys are stored on user devices, and no bastion hosts are required. The Gateway uses short-lived SSH certificates to authenticate each connection.
• Full session auditing. Security and DevOps teams get end-to-end visibility from network-level access to individual commands run on the server. All user activity is logged and attributed to specific identities. Session recordings are stored in asciicast v2 format on your own infrastructure, available for replay or export to a SIEM or object storage.
• Unified policy management. A single policy engine governs both network and SSH access, so there’s no separate credential management or policy configuration to maintain.

How it works

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

[ SSH Client ] ── Twingate Client ── Connector ──> [ Gateway ] ──> [ SSH Server ]
             <====== Twingate Authentication & Authorization ======>

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).

This means:

• No SSH keys are distributed to users. Users authenticate via SSO; the Gateway handles credential management.
• No Trust On First Use (TOFU). The Gateway uses a certificate from a known CA, so users are never prompted to accept an unknown host fingerprint. The Twingate Client syncs the CA’s public key to ~/.ssh/known_hosts automatically.
• No bastion host required. The Gateway replaces the need for a separately managed jump server.

The Gateway records all user actions and commands, exporting session recordings to stdout. You can forward those logs to any destination: a SIEM, S3 bucket, or any other log management system.

After setting up Privileged Access for SSH, you’ll see a new Resource in the Admin Console with the type SSH Server. When viewing the Resource, you’ll also see the Gateway associated with it.

Components

Gateway

The Twingate Gateway is the core component of Privileged Access for SSH. It is a standalone Layer 7 reverse proxy that:

• Terminates the inbound SSH session from the Twingate Client
• Authenticates to the target SSH server using certificate-based authentication
• Maps the Twingate user identity to the appropriate SSH account on the target server
• Records the full session and exports it to stdout 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 SSH certificates that the Gateway uses to authenticate to target servers. 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.

Supported protocols and platforms

Privileged Access for SSH supports all SSH clients (OpenSSH, PuTTY, Termius) and the following usage patterns:

Privileged Access for SSH also supports the following Certificate Authority integrations:

How to set it up

Prerequisites

• A Remote Network with at least one running Connector at version 1.82.0 or later
• The Twingate Client at version 2025.310 or later (macOS, Windows, or Linux)
• A host (or Kubernetes cluster) in your Remote Network where the Gateway will run

Recommended approach

We recommend using Terraform to create the Certificate Authority, deploy the Gateway, and set up the SSH Resource. The Terraform provider can deploy the Gateway alongside Connectors and is well-suited if you’re already provisioning infrastructure as code.

See the Getting Started with IDFW SSH using Terraform guide for a step-by-step walkthrough, or the Gateway deployment repository for configuration examples and reference architectures.

Create the Certificate Authority (optional manual setup)

If you prefer to create CAs manually instead of through Terraform:

• In the Admin Console, navigate to Settings > Certificate Authorities.
• Click Add Certificate Authority and select X.509.
• Provide a name and paste in your X.509 certificate in PEM format. Click Save.
• Click Add Certificate Authority again and select SSH.
• Provide a name and paste in your SSH public key. Click Save.

Configure the SSH server

Each target SSH server must be configured to trust the SSH CA:

# Add the SSH CA public key to /etc/ssh/trusted_ca_keys
echo "<your-ssh-ca-public-key>" >> /etc/ssh/trusted_ca_keys

# Add the following to /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/trusted_ca_keys

# Restart sshd
sudo systemctl restart sshd

User configuration

After a user is granted access to an SSH Server Resource, they need to sync the SSH configuration on their machine. This sets up the necessary entries in ~/.ssh/known_hosts so that SSH connections to Twingate-managed Resources are automatically routed through the Gateway.

To sync the SSH configuration:

• Open the Twingate Client.
• Under More, select Auto-sync SSH Server Configuration. This updates all SSH Resources and keeps the configuration updated automatically.

Client version

All users accessing Privileged Access for SSH need to be on at least Client version 2025.310. Privileged Access for SSH is available on macOS, Windows, and Linux.

Connecting

Once the SSH config is synced, connect using standard SSH tooling with no additional steps:

# Interactive shell
ssh my-server.int

# Run a remote command
ssh my-server.int "ls -la /var/log"

# File transfer
scp ./file.txt my-server.int:~

# SFTP session
sftp my-server.int

# Rsync
rsync -av ./directory/ my-server.int:~/directory/

The Twingate Client handles authentication transparently in the background.

Session recording

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

You can choose how to forward and store session logs:

• SIEM integration: Stream stdout from the Gateway pod or container to your SIEM (Splunk, Datadog, Elastic).
• Object storage: Export logs to S3 or GCS for long-term retention and compliance.
• Session player: Use the Twingate session player at twingate.com/sessionplayer to replay sessions by uploading or pasting a log file. The player is also accessible from the Resource detail page in the Admin Console.

Security considerations

No SSH keys on user devices

Twingate removes the need to distribute SSH key pairs to users. Authentication relies on your identity provider and certificate-based authentication between the Gateway and the SSH server. If a user’s Twingate access is revoked, their SSH access is removed immediately with no key cleanup required.

No Trust On First Use

Traditional SSH requires users to manually verify a server’s fingerprint on first connection. Twingate avoids this by using a certificate issued by a known CA, and the Twingate Client syncs the CA’s public key to ~/.ssh/known_hosts. Users won’t see TOFU prompts.

Private networking

All SSH Server Resources are hidden from the public internet. Connections are made exclusively through the Twingate Client, over the same private networking layer that protects all other Twingate Resources.

Policy reuse

The same Security Policies used for network access (device posture checks, geoblocking, and time-based access) apply to SSH Resources. This keeps least-privileged enforcement consistent across your infrastructure from a single policy engine.

Limitations

• X11 forwarding is not supported.
• Privileged Access for SSH is available on macOS, Windows, and Linux clients only. Mobile clients are not supported.

Frequently asked questions

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

No. Twingate Privileged Access for SSH can coexist with existing SSH authentication methods. 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 stdout on the Gateway, and you are responsible for forwarding and retaining them.

Does this replace my bastion host?

Yes. The Twingate Gateway provides equivalent functionality to a bastion host (proxying connections to private SSH servers) while adding identity propagation, session recording, and zero trust access controls.

What happens when a user’s access is revoked in Twingate?

Access is revoked immediately. Because no SSH keys are distributed to user devices, there is nothing to clean up. The user won’t be able to authenticate through the Gateway the next time they attempt to connect.

Guides

• Remote development with Twingate SSH — Set up VS Code, JetBrains, and Cursor for remote development
• Managing contractor and vendor SSH access — Grant time-limited access with automatic expiration
• SSH session recording for compliance — Configure session capture and SIEM forwarding
• Automating infrastructure with Ansible — Run playbooks over Twingate SSH with no key management
• Getting Started with IDFW SSH using Terraform — Deploy SSH Certificate Authorities, Resources, and Gateway config with Terraform

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