Configure Tailscale SSH

Tailscale SSH uses tailnet identity and policy instead of distributing a separate user SSH key for each connection.

When it is on, the Tailscale client on the server handles connections to TCP port 22 that arrive over the tailnet, and it authenticates them with your tailnet identity. No authorized_keys files to distribute, no key rotation when someone leaves. Access follows the policy file.

Enable it on the server

Enable it on the destination with tailscale set --ssh:

sudo tailscale set --ssh

One warning before you run it: existing connections to the Tailscale IP can hang when you enable it, because the client takes over port 22 handling on the tailnet interface. Keep your recovery session open, the one on the public address or console, while you flip this switch.

Permit it in policy

The policy must permit both network access to TCP port 22 and an entry in the ssh section for the destination and operating-system users:

{
  "ssh": [
    {
      "action": "accept",
      "src": ["flavio@example.com"],
      "dst": ["tag:server"],
      "users": ["ubuntu"]
    }
  ]
}

The users list names the OS accounts the source may become. Granting root here is possible and should be rare. Name the specific unprivileged account the work needs.

Test and verify the boundary

ssh ubuntu@lab-server

The connection authenticates through Tailscale. Identity came from the tailnet, not from a key in ~/.ssh.

Keep your recovery session open, enable Tailscale SSH, test a new session, then confirm an unapproved source cannot connect. Have a second user try, or temporarily remove your ssh rule and watch the connection be rejected.

The detail worth remembering: Tailscale SSH only answers on the tailnet path. SSH to the public address still goes through sshd and normal keys. That is your migration safety net, until you deliberately close it.