Tailscale SSH: authentication, devices and recording

Tailscale SSH lets Tailscale manage Secure Shell (SSH) authentication and access inside your tailnet, your Tailscale network. Its embedded server handles connections to the destination's Tailscale address on port 22, using Tailscale identity instead of a client SSH key or account password. Ordinary SSH over Tailscale keeps your existing SSH server and authentication, while Tailscale Privileged Access Management (PAM), currently documented as beta, proxies access through a connector.

In short:

• Ordinary SSH. Keep your existing SSH server, keys and account authentication over the Tailscale network.
• Embedded SSH. Use Tailscale identity and SSH access policy to log in to supported destinations.
• PAM proxy. Let a connector handle upstream SSH credentials and mediate access to an existing server.

What Tailscale manages when you use SSH

Three connection paths with different login handlers. Ordinary SSH is shown on its usual port 22; its server can use another configured port.

These three paths differ in which component accepts your connection and handles the login.

Using an SSH client or a Tailscale address alone doesn't identify the mode. Turning on embedded Tailscale SSH sends tailnet traffic to port 22 on that device's Tailscale address to Tailscale's own server. That doesn't replace the standard SSH server for traffic arriving through other network addresses.

Ordinary SSH uses Tailscale as the network layer, leaving SSH authentication separate. PAM adds a proxy: the connector applies access controls, then connects to the upstream SSH server on your behalf.

Who can sign in and which passwords still matter

Permission to reach a host and permission to log in as a host user are separate checks.

Embedded SSH needs both network permission and an SSH rule allowing the destination username. It uses existing host accounts, not a new account created by signing in to Tailscale. Tailscale also distributes public SSH host keys so your client can recognize the destination, while the private host key stays on that host. A host key identifies the server, not the person logging in.

Embedded SSH already knows who is connecting through Tailscale node keys. It uses SSH authentication type none, so it doesn't ask for a client key or password. If your client can't use none, the documented +password username suffix simulates password authentication without requiring the destination user's password. Check mode adds a fresh sign-in with your identity provider, not a destination-account password check. Removing the SSH login password doesn't remove later password prompts or privilege checks inside the host.

PAM's connector can sign in to the upstream server with a password, private key or certificate, so you don't need those credentials yourself. Password and private-key modes ignore your client's username and use the username configured for the service. With certificate authentication, a client-supplied username is used only when Prompt Client for Username is selected. For certificate authentication, the upstream OpenSSH server must trust the Tailscale PAM SSH certificate authority (CA).

Ordinary SSH keeps its separate client authentication and host-key checks. For PAM, don't confuse the connector's upstream login method with its upstream host-key policy. Check that policy separately if server identity checks affect your choice.

Which devices can connect and which can receive connections

A device's ability to start an SSH session doesn't mean it can host the embedded SSH server.

Windows and mobile devices running Tailscale can initiate embedded SSH connections with a compatible SSH client. They aren't supported destinations for the embedded server.

Embedded destinations require Tailscale v1.24 or later. On macOS, support means the open-source tailscale plus tailscaled command-line interface (CLI) variant, not every macOS app variant. Synology and QNAP devices can't run the embedded server. A host reachable behind a subnet router can't receive embedded SSH connections unless it also runs Tailscale and meets the server requirements.

Ordinary SSH eligibility follows the installed SSH software and network reachability, not the embedded server's platform list. PAM requires an installed, online connector that can reach the upstream SSH server. For a native SSH client, your device needs Tailscale installed and signed in, or you can use PAM's browser client. That browser route uses PAM's connector, not the embedded server path.

What gets recorded and where the recordings go

Access logs show connection attempts. Session recordings let you review activity inside a session.

Ordinary SSH may use separate recording tools. Their capabilities are a separate choice, not a recording feature supplied by the Tailscale network layer.

Embedded Tailscale SSH itself is available on all plans. Its documented recording path streams session content to special recorder nodes within your tailnet. Those nodes can run as Docker containers and store recordings on the host's disk, Amazon S3 or S3-compatible object storage. Tailscale states that it never has access to recordings on this path.

PAM logs both successful and denied connection attempts. When recording is enabled for an SSH service, you can review terminal replay, full text and events, depending on the session. Access logs alone aren't a recording of everything done inside the session.

PAM stores recordings for you by default, while custom storage in your own Amazon S3 bucket requires the Premium plan. Using your own bucket changes the storage destination, not the full data path. Recordings still pass through the Tailscale PAM application programming interface (API) before reaching your bucket. The connector doesn't upload them directly to your storage.

Choose the mode by what you need to keep separate

Keep ordinary SSH over Tailscale when you need separate client-key authentication or different SSH permissions for local users sharing a source machine. It's also the documented alternative when you depend on authorized_keys restrictions that limit which commands remote users can run.

Consider embedded SSH when your destinations are supported and Tailscale identity-based login fits your access model. Consider PAM when a connector should hold upstream credentials and mediate access to existing SSH servers. Neither choice removes the need to decide which destination usernames a person should be allowed to use.

The embedded SSH trust warning concerns source machines allowed to initiate outbound Tailscale SSH connections, not every destination running its server. Any local operating system user on such a source can attempt access under that device's Tailscale identity. Server-side policy still restricts the scope of that access. This matters on shared machines and sources running code you don't trust.

Check mode with checkPeriod set to always adds identity-provider approval for every new connection. It's an approval control, not a barrier against malware or untrusted code. SSH rules from tagged source devices, which use policy tags as their identity, can't use check mode.

Before you follow a setup guide, identify your connection path, source identity, destination username and recording data path. Those choices tell you which Tailscale SSH mode you actually need.

Related guides

• Tailscale SSH setup on Linux and macOS
• How to disable Tailscale SSH without disconnecting Tailscale
• Tailscale SSH alternatives with separate host authentication
• SSH from Windows over Tailscale
• Diagnose an embedded SSH activation failure