Tailscale SSH Silently Bypasses authorized_keys Restrictions on Hardened Servers

What happened

A developer writing on dev.to, in a post originally published in Japanese on forge.workstyle.tech, has documented a quiet failure mode in SSH hardening: enabling Tailscale SSH on a host can make authorized_keys restrictions stop applying without any error or warning. The author had scoped a dedicated key so a Mac could only pull finished videos from a Linux machine, yet that same setup happily fetched .bashrc from the home directory.

The setup that should have worked

According to the post, the Linux video-producing machine carried an authorized_keys entry of the form command="rrsync -ro /path/to/deliver",restrict for a dedicated ed25519 key. The rrsync wrapper confines rsync transfers to a single directory, -ro makes those transfers read-only, and restrict disables everything else the key might do. On the Mac side, ~/.ssh/config pinned the host with IdentitiesOnly yes and the dedicated identity file, so no other key would be offered to the server.

Fetching a video from the delivery folder worked as intended. The negative test — pulling a file from outside that folder — also worked, and that was the problem.

Why the restriction was ignored

The decisive detail, the author explains, was that Tailscale SSH was enabled on the Linux machine, with RunSSH: true in the Tailscale configuration. Connections arriving over Tailscale SSH are terminated by tailscaled, the Tailscale daemon, rather than by OpenSSH's sshd. Since authorized_keys is a file that only sshd consults, the command= and restrict options attached to the key were never examined. The restrictions were not weakened or misparsed — they sat on a code path that was never executed.

The fix, and how to verify it

The remedy was a single command on the server side:

tailscale set --ssh=false

After that change, SSH traffic over Tailscale reaches sshd again, and the per-key restrictions take effect. The author's verification routine is worth copying. Check that the permitted operation still works — the delivery folder can be fetched. Then check that the things you meant to deny actually fail: a file outside the target folder such as .bashrc, and an attempt to run an arbitrary command over the connection. The author's core argument is that a successful permitted operation proves nothing about whether the denial side is actually enforced.

Two further traps

Two secondary findings round out the write-up. First, macOS ships an rsync based on openrsync, which rrsync rejected; installing rsync via Homebrew fixed the client. A client-side version mismatch can therefore masquerade as a server configuration failure. Second, logging back into Tailscale with the --ssh flag re-enables Tailscale SSH, restoring the tailscaled path and once again bypassing sshd's key handling. The fix is not one-and-done — the setting needs re-checking after any re-login.

Why it matters

authorized_keys is a load-bearing part of SSH hardening. Forced commands, restrict, no-pty and similar options are how teams scope automation, backup and deployment keys to the minimum they need. Tailscale SSH is attractive because it replaces per-user key juggling with tailnet-based access control, but this post shows the two mechanisms do not compose: on a host where Tailscale SSH is active, per-key policy in authorized_keys is effectively dead configuration. Anyone running restricted keys alongside Tailscale should confirm which daemon terminates their connections, disable Tailscale SSH where per-key restrictions matter, and test the denials rather than only the allowed path. Access control that has never been observed to fail is indistinguishable from access control that is not running at all.