Skip to content
Lobster

Why Tailscale SSH

Why Tailscale SSH

An always-on AI agent with shell access, email delegation, and calendar control is a high-value target. The SSH surface that enables remote management must be as small as possible. Tailscale SSH eliminates entire categories of attack by removing the agent from the public internet entirely.

What Is Tailscale?

Tailscale is a zero-config mesh VPN built on WireGuard. It creates a private network — called a tailnet — across your devices: laptops, phones, servers, cloud VMs.

Key properties:

  • Every device gets a stable IP and a MagicDNS name (e.g., ssh my-agent)
  • Traffic is encrypted end-to-end using WireGuard; Tailscale’s coordination server never sees your data
  • Works through NAT and firewalls automatically — no port forwarding, no dynamic DNS
  • Free tier supports up to 100 devices and 3 users
  • Your tailnet is invisible to the public internet — devices only talk to each other

The Problem with Traditional SSH

Exposing port 22 to the internet creates a permanent attack surface:

  • Constant brute-force attacks — Any public SSH port receives thousands of automated login attempts per day
  • Credential stuffing — Password-based SSH is trivially broken by dictionary attacks
  • Key theft — Even key-based SSH is vulnerable if a client machine is compromised and ~/.ssh/ is exfiltrated
  • Port forwarding — Opening port 22 through your router adds another configuration surface to maintain and audit
  • Service fingerprinting — An exposed SSH banner tells attackers the OS version and SSH implementation

For a home network running an always-on agent Mac, this is especially risky. The machine is unattended, can’t prompt for 2FA, and has broad access to personal data.

How Tailscale Changes the Model

Tailscale SSH replaces the traditional SSH model entirely:

  • Zero exposed ports — No listener on the public internet. Internet scanners cannot find the agent.
  • Identity-based access — Authentication is tied to device identity and SSO, not SSH keys or passwords
  • WireGuard encryption — All connections use modern, audited cryptography end-to-end
  • No port forwarding — Connections traverse NAT automatically via DERP relays (encrypted; relays can’t read traffic)
  • Centralized access control — ACLs are managed in the Tailscale admin console, not in scattered authorized_keys files

Comparison

AspectTraditional SSHTailscale SSH
Port exposurePort 22 open to the internetNo public ports
AuthenticationKeys or passwordsDevice identity + SSO
Brute-force riskConstant automated attacksNot possible — no public listener
Key managementManual distribution of authorized_keysAutomatic via coordination server
Access controlPer-host authorized_keys and sshd_configCentralized ACLs in admin console
Audit loggingLocal syslog (if configured)Tailscale admin console
Network traversalPort forwarding requiredWorks through NAT automatically
EncryptionSSH protocol (various ciphers)WireGuard (ChaCha20-Poly1305)

Defense in Depth: Disabling macOS sshd

Once Tailscale SSH is active, the built-in macOS SSH server should be disabled entirely:

Terminal window
sudo systemsetup -setremotelogin off

This eliminates the last remaining attack surface on port 22. The agent Mac now has zero SSH-accessible ports on any public or local network. The only way to reach it is through the tailnet — which requires a device that has been authenticated and authorized via Tailscale.

This is not optional hardening — it’s the critical step that closes the gap. Running both Tailscale SSH and macOS sshd simultaneously means you’ve added a new access path without removing the old one.

ACLs and Least-Privilege Access

Tailscale ACLs control which devices can SSH to the agent, with different authorization levels:

  • accept — Auto-approve the connection (used for personal devices you physically control)
  • check — Require browser-based re-authentication before allowing the connection (used for server nodes or less-trusted devices)

Example ACL structure:

{
  "acls": [
    {
      "action": "accept",
      "src": ["autogroup:self"],
      "dst": ["tag:agent:22"],
      "comment": "Owner devices can SSH to agent without re-auth"
    },
    {
      "action": "check",
      "src": ["tag:server"],
      "dst": ["tag:agent:22"],
      "comment": "Servers must re-authenticate via browser"
    }
  ]
}

This means your personal MacBook can SSH freely, but a CI server or automation host must pass a browser check first — adding a human-in-the-loop for less-trusted access paths.

Tailscale Lock: Protecting Against Coordination Server Compromise

The coordination server is the one piece of Tailscale infrastructure you don’t control. If it were breached, an attacker could theoretically add a rogue node to your tailnet.

Tailscale Lock mitigates this by requiring physical device approval (from your iPhone, MacBook, etc.) before any new node can join the tailnet. Even a compromised coordination server cannot authorize a new device without your explicit approval on a trusted device.

For an agent deployment, this is supply-chain protection for the network itself.

Why This Matters for AI Agents

An AI agent with shell access, email delegation, and calendar control is not a typical SSH host. It’s a high-value target because:

  • Broad tool access — The agent can read email, manage calendars, execute commands, and access personal data
  • Always-on — The machine runs unattended 24/7, unable to prompt for interactive 2FA
  • Elevated trust — Family members trust messages from the agent; a compromised agent could socially engineer its own users

Tailscale SSH + disabled sshd means the agent is invisible to internet scanners. Combined with tool restrictions, exec approvals, and Docker sandboxing, this creates layered defense that limits the blast radius of any single compromise.

Remote management still works seamlessly — just ssh agent-name from any device on your tailnet. No VPN client to configure, no ports to open, no keys to distribute.

Further Reading