Tailscale SSH: Investigation and remediation update

Original Article ↗ Hacker News Discussion ↗

Tailscale’s recent disclosure of privilege-escalation flaws in its Tailscale SSH feature has raised concerns about relying on a VPN provider for both network access and authentication. Commenters note the bugs mainly affect setups that delegate SSH authorization to Tailscale rather than using standard OpenSSH, and debate the ethics of the near-immediate public disclosure that gave the company little advance warning. The incident reinforces broader worries about Tailscale’s growing feature set and attack surface, prompting some to favor simpler WireGuard‑based setups and to treat Tailscale as just one layer in a defense‑in‑depth strategy.

Status of Tailscale SSH Feature

  • Multiple commenters clarify that Tailscale SSH is not enabled by default; it must be explicitly turned on.
  • It is not available on all platforms.
  • Many users report never using it, instead running standard OpenSSH over the tailnet.

Nature and Severity of the Vulnerabilities

  • The main issues discussed are privilege escalations in Tailscale SSH: an already-authorized Tailscale SSH user can sometimes gain more privileges than their local account should have.
  • A former employee/administrator notes the impact is limited to:
    • Nodes where Tailscale SSH (not regular SSH) is enabled.
    • ACLs that allow non-root, non-sudo accounts; escalation then breaks least-privilege assumptions.
  • Not an unauthenticated “RCE for everyone” in current public understanding, but several mention ongoing research into possible unauthenticated angles.
  • Headscale deployments using Tailscale SSH are also affected, since the bug is in tailscaled.

Disclosure and Communication

  • Some criticize the vague wording (“most”, “in some circumstances”) as weaselly and fear it hides worse bugs.
  • Others see the language as cautious mid-investigation.
  • The short pre-publication notice window given to Tailscale is widely viewed as questionable.

Complexity, Attack Surface, and Product Direction

  • Several commenters argue Tailscale has become feature-bloated (SSH, Taildrop, Taildrive, Funnel, etc.), expanding the attack surface.
  • There is concern that basic issues (e.g., input validation) keep appearing and that deep code audits seem ad hoc.
  • Some organizations report moving off Tailscale due to perceived risk.
  • Others note you can rebuild tailscaled with many features omitted, but this is unofficial and support-wise awkward. A first-class “minimal” build is requested.

Usage Patterns and Alternatives

  • Many say they disable Tailscale SSH and rely on OpenSSH over Tailscale, or just classic SSH/OpenVPN/WireGuard with manual key management.
  • Enterprise-oriented users highlight benefits of Tailscale SSH (centralized auth, ACLs, MFA, audit trail), but accept it increases complexity.
  • Alternatives mentioned include plain WireGuard, Headscale, NetBird, Nebula, IPsec, and DIY VPS hub setups, each trading convenience for control and reduced feature surface.

Security Posture and Best Practices

  • Strong sentiment that Tailscale should be treated as one defensive layer, not the sole gatekeeper:
    • Services should still enforce their own auth (HTTPS, app-layer auth).
    • Tailnet exposure should be treated similarly to internet exposure.
  • Debate over whether least-privilege setups make this bug more serious (because escalation breaks deliberate constraints) versus less impactful scenarios where Tailscale SSH already grants root/sudo.
  • Broader themes: defense in depth, minimizing attack surface, and skepticism of “roll your own SSH server” versus sticking to OpenSSH.