Review local account names as well as network permission in Tailscale SSH

Permitting port 22 and permitting a local login identity are separate decisions.

Source facts

Tailscale SSH requires both network permission between the devices and an SSH policy permitting the source, destination, and host username. It uses local accounts that already exist on the destination; it does not create those accounts. The documentation warns that autogroup:nonroot can authorize any non-root user on a destination when a rule is broadened beyond a user’s own devices. Check mode can require reauthentication before a connection and supports an explicit validity period. Tagged-device source rules cannot use check mode.

Source: Tailscale — SSH.

Applicability

This applies to Tailscale-managed SSH on supported destination platforms. An ordinary OpenSSH service reached over a Tailscale network address has its own authentication and account controls.

DSE recommendation

DSE recommends listing the exact local accounts required for each destination class. Do not retain a broad non-root selector merely because it appeared in an own-device example. Review the source identity, target tag, network permission, and local-user permission together. Apply check mode where interactive identity verification is appropriate, while designing automation separately. Keep another approved administration route available during initial enablement, and document which host accounts remain reachable through other network paths or SSH implementations.

Verification

In a test environment, try the approved local account and an existing but unauthorized account from the same source. Check that network connectivity alone does not grant the second login. Exercise the reauthentication period where check mode is used, and record the effective policy rather than only its intended design.

Official reference

Tailscale — SSH. Reviewed October 15, 2026.