SSH Overview

Authentication

The Twingate Client authenticates to the Gateway using a Gateway Access Token (GAT). See How It Works for details. The Gateway handles authentication to the upstream SSH server on behalf of the user - ssh does not need a private key or password.

The Gateway connects to the upstream SSH server using SSH certificates signed by a Certificate Authority (CA), authenticating as a predefined user. This eliminates the need for individual SSH keys on each server.

The Gateway supports three CA modes for signing certificates:

• Auto-generated: Generates a CA keypair at runtime. Suitable for development and testing.
• Manual: Loads a CA private key from a file or Kubernetes secret. Recommended for production without Vault.
• Vault: Uses HashiCorp Vault's SSH secrets engine for certificate signing, with support for Token, AppRole, GCP, and AWS authentication.

Audit

The Gateway logs all SSH sessions with user identity attribution, including connection metadata (client/server protocol versions, session ID), channel types, and request types. Interactive sessions (shell, exec) are recorded in Asciicast v2 format for playback and forensic review.

See Session Recordings for how to collect and store session recordings.

Client Configuration

The Twingate Client automatically syncs ~/.ssh/known_hosts with the Gateway's host CA public key, allowing the SSH client to verify the Gateway's identity. The synced configuration contains no credentials - no private keys or passwords to rotate or manage. Auto-sync keeps the configuration current as resources are added or removed.

Capabilities

The Gateway supports standard SSH workflows, all fully audited with user identity attribution:

• Interactive shell sessions and remote command execution
• File transfer via SFTP
• Local port forwarding (ssh -L)
• Remote port forwarding (ssh -R)