SSH Session Recording for Compliance
A complete terminal recording of every SSH session, tied to the authenticated user's real identity. No separate session recording product needed.
Twingate’s SSH Gateway provides automatic session recording for all SSH connections routed through it. Every interactive shell session, remote command execution, and file transfer is logged in asciicast v2 format and tied to the user’s SSO identity. Recordings stay entirely on your infrastructure — they never touch Twingate’s servers. Forward them to your SIEM, archive them in S3, or replay them in a browser for incident investigation.
This guide explains how session recording works, what gets captured, how to forward recordings to your security infrastructure, and how recordings satisfy requirements for SOC 2, ISO 27001, PCI-DSS, and HIPAA.
How recording works
The SSH Gateway is a Layer 7 reverse proxy that sits between users and SSH servers. When a user runs ssh my-server.int, the Twingate Client routes the connection to the Gateway. The Gateway terminates the inbound SSH session, authenticates the user via your identity provider, and proxies the connection to the target server.
During the session, the Gateway captures all terminal I/O — every command, every keystroke, every output line — in asciicast v2 format. The recording includes timing metadata, so you can replay sessions in real time and see exactly what the user saw. Each recording is tagged with the authenticated user’s real identity from your identity provider (Okta, Entra ID, Google Workspace, etc.), not a shared Linux username.
Recordings are exported to the Gateway container’s stdout as structured JSON events. This follows standard container logging patterns: the Gateway doesn’t write to disk or ship logs to a proprietary backend. You capture stdout using your existing log infrastructure, the same way you collect logs from any containerized service.
Recording is automatic and always-on. There’s no configuration to enable or disable recording per-session. Every SSH connection routed through the Gateway is recorded by default.
What’s recorded and what’s excluded
Interactive shell sessions: Fully recorded. Every command entered, every output line, and all timing information. If a user opens a shell and runs commands, the entire session is captured.
Remote command execution: Fully recorded. When a user runs ssh server "ls -la" to execute a single command without an interactive shell, the command and its output are recorded.
Binary file transfer payloads (SCP content): Automatically excluded. When a user transfers a file via SCP, the connection metadata is logged (user, timestamp, target server), but the binary content of the file is not recorded. This keeps log sizes manageable and avoids capturing large payloads that don’t provide meaningful audit value.
SFTP sessions: Connection logged, binary payloads excluded. SFTP connections are recorded with metadata (user, server, timestamp), but file content transferred over SFTP is not captured.
Every recording includes the authenticated user’s real identity. When a developer authenticates via Okta and SSHs into a server as the ubuntu user, the session log records the developer’s Okta email, not the shared ubuntu account. This ties every action to a specific person, which compliance frameworks require for traceability.
Forwarding to a SIEM
The Gateway exports session logs to stdout as JSON events. To forward to Splunk, Datadog, Elastic, or any SIEM, capture the Gateway container’s stdout and route it using your existing log pipeline.
In Kubernetes, this means configuring a log collector to capture stdout from the Gateway pod. Most Kubernetes log collectors (Fluentd, Fluent Bit, Datadog Agent, Splunk Connect for Kubernetes) are configured to capture stdout from all pods by default. If you’re already collecting application logs from your cluster, you’re already collecting session recordings.
For VM deployments, redirect Gateway stdout to a file and use a log shipper (Filebeat, Fluentd, Vector, etc.) to forward it to your SIEM.
Conceptual pattern:
SSH Gateway → stdout → Log collector → SIEMIn Kubernetes:
- The Gateway pod writes session logs to stdout
- A DaemonSet-based log collector (Fluentd, Fluent Bit, etc.) captures stdout from the pod
- The log collector forwards events to your SIEM backend
In VM deployments:
- Run the Gateway process with stdout redirected to a file or systemd journal
- Configure a log shipper to tail the output and forward to your SIEM
The session logs are structured JSON, so you can parse them in your SIEM to extract user identity, target server, session duration, and commands executed. Use these fields to build dashboards, alerts, and compliance reports.
Archiving to object storage
Many compliance frameworks require multi-year log retention. To satisfy long-term retention requirements, route Gateway stdout to a log pipeline that writes to object storage (S3, GCS, Azure Blob Storage).
Pattern:
SSH Gateway → stdout → Log collector → Object storage (S3/GCS)For example, configure Fluentd or Fluent Bit to write session logs to an S3 bucket with a lifecycle policy that transitions logs to Glacier after 90 days and retains them for 7 years. This gives you low-cost, long-term retention that satisfies regulatory requirements without manual archival workflows.
Object storage also provides immutability guarantees. Enable S3 Object Lock or GCS Bucket Lock to ensure session logs cannot be modified or deleted, which is required for certain compliance frameworks.
Replaying sessions
You have three options for replaying recorded sessions:
1. Browser player
Upload or paste an asciicast log file at twingate.com/sessionplayer. The player runs entirely in your browser. No data is uploaded to Twingate’s servers. This is the fastest way to review a session during an incident investigation.
2. Admin Console
Navigate to the Resource detail page for an SSH Resource in the Twingate Admin Console. The session recordings section lists all recorded sessions for that resource. Click a session to replay it directly in the console.
3. Any asciicast-compatible player
Session logs use asciicast v2, an open standard for terminal recordings. You can replay them with any compatible player, including the open-source asciinema player. This gives you flexibility if you need to integrate session replay into your own internal tooling.
Compliance mapping
Session recording satisfies key requirements across multiple compliance frameworks. Here’s how it maps to specific controls:
| Framework | Control | Requirement | How session recording satisfies it |
|---|---|---|---|
| SOC 2 | CC6.1 | Logical and physical access controls are designed and operated to restrict access to systems and data. | Session recordings provide evidence that access to systems is authenticated (via SSO identity) and auditable. Every access event is tied to a real user, not a shared credential. |
| SOC 2 | CC6.2 | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users. | Session logs prove that access was granted only to authorized users. Each recording includes the authenticated SSO identity, demonstrating that the user was authorized via the identity provider. |
| SOC 2 | CC6.3 | The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design. | Session recordings show what actions each user took after access was granted. You can replay sessions to verify that users accessed only the systems they were authorized for and took only permitted actions. |
| ISO 27001 | A.9.4 | System access should be monitored to detect and respond to unauthorized access. | Session recordings provide complete monitoring of system access. Every command executed during an SSH session is captured and tied to the user’s identity. |
| ISO 27001 | A.12.4 | Logging and monitoring of user activities, exceptions, faults, and information security events should be performed. | Session logs record all user activities during SSH sessions. The asciicast format captures not just commands but also output, timing, and context, sufficient to reconstruct exactly what happened during an incident. |
| PCI-DSS | Requirement 10 | Track and monitor all access to network resources and cardholder data. | Session recordings create an audit trail for all SSH access to systems in the cardholder data environment. Each recording is immutable (when stored in object storage with Object Lock) and tied to a real user identity, satisfying PCI’s requirement for traceable access logs. |
| HIPAA | §164.312(b) | Implement hardware, software, and procedural mechanisms that record and examine activity in information systems containing ePHI. | Session recordings provide audit controls for SSH access to systems containing electronic protected health information. Every session is logged with user identity, timestamp, and a full recording of commands executed. |
Common across all frameworks: Session recordings are tied to the user’s real SSO identity, not a shared Linux username. When a user authenticates via Okta and SSHs into a server as the ubuntu user, the session log records the user’s Okta email. Compliance frameworks require this traceability as evidence of who accessed what system and when.
Data sovereignty
Session recordings never leave your infrastructure. The Gateway runs in your environment — in your Kubernetes cluster or on your VMs — and exports logs to stdout. Those logs are captured by your log collector and sent to your SIEM or object storage, all within your own network.
Twingate has no access to session content. The Twingate control plane handles policy decisions (who has access to which SSH Resources), but session recordings stay entirely in your custody. This satisfies data residency requirements for industries and regions with strict data sovereignty rules.
You control log retention, storage location, and access policies. If your compliance framework requires logs to stay in a specific geographic region or to be retained for a specific duration, you configure that in your own logging pipeline and object storage settings.
Summary
Twingate’s SSH Gateway provides automatic session recording for all SSH connections. Recordings are captured in asciicast v2 format, exported to stdout, and tied to the user’s real SSO identity. They stay entirely on your infrastructure — forward them to your SIEM, archive them in S3, or replay them in a browser.
No separate session recording product is required. Session recording is built into the Gateway and always-on by default. It satisfies audit requirements for SOC 2, ISO 27001, PCI-DSS, and HIPAA without additional configuration or third-party tooling.
For an overview of how Twingate SSH works, see the SSH Privileged Access overview.
Join us in the community subreddit to share how you’ve set up session recording and what compliance workflows you’ve built.
Last updated 13 minutes ago