Twingate vs Tailscale for SSH privileged access

Choose Twingate SSH Gateway for certificate-based Secure Shell (SSH) access to target servers and always-on terminal recordings kept on your infrastructure. Choose Tailscale Privileged Access Management (PAM) if you need password, key or certificate authentication upstream, with separate permissions for shells, commands, file transfer and port forwarding.

In short:

• Gateway recordings. Routed SSH sessions get always-on terminal recordings kept on your infrastructure.
• PAM permissions. Separate controls cover shells, commands, file transfer, requested usernames and port forwarding.
• PAM storage. Your own Amazon S3 storage bucket requires Premium and still receives recordings through the PAM application programming interface (API).

Choose by your SSH access requirements

Compare Gateway and remote-server PAM as SSH proxies, not as the full networking products.

Gateway is the stronger fit when certificate-based access and customer-held recordings drive your choice. PAM is the stronger fit when you need several upstream authentication methods and separate SSH permissions. Both need a pilot before you rely on them for privileged access.

Check which identity reaches the server

Being allowed to use the proxy isn't the same as being allowed to log in to the target server. Check both decisions. A certificate authority (CA) signs certificates used to prove an identity. This comparison covers remote-server PAM, not embedded Tailscale SSH.

Each proxy connects your identity to a separate upstream credential.

With PAM password or key authentication, typing another username doesn't change the target account. Certificate mode uses your requested username only when Prompt Client for Username is selected and permissions allow it. For production, Tailscale recommends keeping upstream credentials local to the connector through a supported secret source.

Gateway can sync the SSH CA’s public key to ~/.ssh/known_hosts, letting your client trust the Gateway’s host certificate without a first-use prompt. That trust concerns the Gateway, not the target server behind it. Before rollout, check how each proxy validates the upstream server’s identity and rejects an unexpected host key.

Check what a session can open

Port forwarding uses an SSH connection to carry another connection. Here, that includes Transmission Control Protocol/Internet Protocol (TCP/IP) traffic. File-transfer support includes SSH File Transfer Protocol (SFTP).

These are documented features and settings, not proof of every privilege boundary.

PAM’s exec permissions control requests to run remote commands. Regular expressions, which match text patterns, can restrict those requests to specific commands. Requested-username controls apply to certificate-based upstream authentication, not to the fixed account used by password or key modes.

Gateway's overview lists forwarding support without specifying a matching permission model or forwarding default. A supported feature doesn't tell you whether your policy can restrict it as needed. Test local and remote forwarding, plus alternate access routes, before relying on either proxy’s boundary.

Check what the audit trail keeps

The PAM session-log view explains why successful or denied connections were allowed or rejected, including evaluated grants. Terminal replay shows terminal activity. Neither proxy's documentation establishes that it captures every SSH data path.

Compare recording content, storage and collection separately.

Gateway’s overview names stderr for export, while its recording guide names stdout. These are the container’s error-output and normal-output streams. Check which stream your deployed build uses before wiring collection. The overview’s asciicast v2 terminal-replay format and the guide’s structured JavaScript Object Notation (JSON) events don’t, by themselves, show incompatible recordings.

For Gateway, you run collection and retention. For PAM, confirm the retention period and file-transfer payload evidence your audit policy requires. Amazon S3 is PAM’s only documented custom storage destination, and owning the bucket doesn’t remove API transit. Switching PAM storage doesn’t migrate old recordings and removes their replay availability in the admin console.

Check what you need to run

Twingate Gateway is in Early Access, and Tailscale PAM is in beta.

Gateway needs an X.509 CA for the client-to-Gateway connection and an SSH CA for target login and Gateway identity. PAM needs an online connector that can reach the target SSH server.

The deployment requirements affect which devices can connect and what you must operate.

PAM’s browser client appears as a temporary device in your Tailscale network, also called a tailnet. If device approval is enabled, an admin must approve that browser device before it can connect. Confirm PAM client compatibility and full plan eligibility before committing.

Keep the SSH investigation separate from the choice

Tailscale's October 28 findings and fixes confirms that v1.104.4 addresses the disclosed embedded-SSH issues. The forwarding bulletin concerns an already-authorized SSH session gaining privileges beyond its configured local account. The Tailworm remediation guide maps the confirmed issues and their conditions.

For Tailscale SSH, tighten access policies, disable unneeded forwarding, and use your platform’s supported update path to install the applicable client update and verify its version. Mitigations remain relevant while a deployment is unpatched. These embedded-SSH findings don't establish that remote-server PAM or Gateway shares the issue, and they don't prove either product is immune.

Test the controls before you switch

Run a small acceptance pilot against your access and recording requirements, not just the investigation. Test only systems you own or administer, and keep a controlled recovery path while changing access.

1. Check the upstream account.

Confirm that an allowed connection reaches the intended server account. In a mode that supports username selection, try an account your policy should deny and expect rejection. With PAM password or key authentication, expect the configured account instead of a client-supplied username.

2. Try allowed and denied actions.

Test shells, remote commands, file transfers, and local and remote forwarding against your intended policy. Allowed actions should work, and denied actions should fail. This checks those specific permission boundaries, not every way to reach the server.

3. Check the session evidence.

Look for the person, device, target and relevant activity your audit policy requires. PAM authorization details should explain why access succeeded or failed. Missing required fields mean your evidence isn’t ready for that requirement.

4. End the session and check retained recordings.

End a recorded session and check that its evidence reached the intended storage destination. For PAM customer S3, confirm the recording exists in your bucket and replay is available in the admin console. For Gateway, check that your collector retained the session and that it can be replayed.

5. Review the routes that remain.

Gateway leaves existing authorized_keys entries unchanged, so adding it doesn’t remove older key-based access. For either mode, decide which retained routes are controlled recovery paths and which must be removed or restricted. This is a general access-path review, not a documented PAM migration feature.

Passing these tests confirms the scenarios you checked. It doesn't cover every alternate route or failure mode. If results differ, inspect grants, upstream account settings, connector or Gateway logs, and the recording pipeline before expanding access. Keep your current provider when it passes the same requirements and switching adds no needed control.

Related guides

• Twingate vs Tailscale: Choose your private-access model
• Tailscale SSH alternatives with separate host authentication
• Tailworm: findings, access conditions and fix status