Learn Tailscale - Tailscale SSH

#Introduction

Classic SSH is painful: creating key pairs, copying public keys to ~/.ssh/authorized_keys on every server, managing passphrases, and disabling password login. The more servers you have, the bigger the management burden — and the higher the risk of keys getting scattered around.

Tailscale SSH eliminates all of that. Authentication uses your tailnet identity: if you're logged into Tailscale as a specific user, that's your identity. No server passwords, no manual key management. Episode 7 covers how to enable this feature, use it daily, and configure its policy through the ACL.

#Tailscale-Based SSH

#Enabling on the Server

On the server side, enable Tailscale SSH with one flag:

sudo tailscale up --ssh

The --ssh flag tells the daemon to listen on port 22 in the Tailscale version. If the server is already running, just use:

sudo tailscale set --ssh

The sudo tailscale set --ssh command enables SSH on an already-running session without disrupting other connections.

#Connecting from a Client

From another device in the tailnet, logging in is a single command:

tailscale ssh devnull@server-home

Without tailscale ssh, you can still use regular SSH:

ssh devnull@server-home

The difference with tailscale ssh: it uses your tailnet identity directly, so user mapping is done by policy, not by an authorized_keys file.

#SSH ACL and Policy

#The ssh Block in the ACL File

Tailscale SSH policy is configured in the ssh block of the ACL file. This determines who can SSH into which node, and as which OS user:

{
  "acls": [
    { "action": "accept",
      "src": ["group:devops"],
      "dst": ["tag:server:22"] }
  ],
  "ssh": [
    { "action": "check",
      "src": ["group:devops"],
      "dst": ["tag:server"],
      "users": ["autogroup:nonroot", "root"] }
  ]
}

The ssh block above uses "action": "check" — permission is granted through an interactive process. This rule lets every member of group:devops sign into all nodes tagged server as a non-root or root user.

#Users and Interactive Sessions

The users section determines which OS users can be used: autogroup:nonroot means users without root privileges, root means root. When a connection is made, Tailscale shows a confirmation prompt if the action is check — this adds a layer of manual approval before the session opens.

tailscale ssh user@node
    |-- tailnet identity check (user/group from SSO)
    |-- 'ssh' policy in the ACL -> check/accept
    |-- mapping to OS user on the server
    +-- secure session with no password/key

#Session Supporting Features

#Reconnect When the Network Changes

Tailscale SSH connections hold sessions better when a device switches networks. When WiFi changes, the SSH connection stays alive as long as the tailnet connection recovers — convenient for long sessions like installing software or running long-lived processes.

#Monitoring Session Integration

Because all sessions run over the tailnet, policy and audit can be enforced centrally. Admins can record who signed into which server through connection logs, without having to watch sessions manually. Combined with the audit log (episode 21), you get a complete access trail.

#You Can Still Use Classic SSH

Tailscale SSH doesn't disable regular SSH. If you still need OpenSSH for specific purposes, both can run side by side — just configure the ACL so port 22 stays accessible to allowed nodes.

#Best Practices

• Enable --ssh on servers and disable OpenSSH password login.
• Use autogroup:nonroot for daily tasks, root for controlled escalation.
• Combine the ssh block with port ACLs for layering.
• Monitor who signs in via the session list in the admin console.

#Closing

Episode 7 made your SSH management much lighter: tailnet identity replaces passwords and manual keys, policy is configured in one place in the ACL file, and sessions are more resilient to network changes.

Key takeaways:

• Enable with tailscale up --ssh or tailscale set --ssh.
• Sign in with tailscale ssh user@host or regular ssh.
• No server passwords and no manual key management.
• Policy is configured in the ssh block of the ACL file with a check action.
• users determines which OS users can be used, including root.
• Sessions survive device network changes.

In the next episode, episode 8, we'll cover CLI configuration and options — using tailscale set and flags like --hostname, --accept-routes, --advertise-routes, --advertise-exit-node, --ssh, --login-server, and --auto-update, plus per-device preference persistence via the prefs file.