Tailnet-only SSH is usually the cleaner default for administration when every operator and recovery path can reach the private network. Public SSH remains defensible when provider recovery, emergency access, automation, or third-party operations make private-only access unsafe.
What changes between the two models?
Public SSH puts an authentication service on the internet and asks hardening, keys, MFA layers, rate limits, and monitoring to carry the exposure. Tailnet-only SSH moves the first reachability boundary to the private mesh, but adds dependencies on the mesh account, client, policy, and control plane.
| Question | Public SSH | Tailnet-only SSH |
|---|---|---|
| Internet scan noise | Expected | Reduced at the SSH service |
| Identity policy | OpenSSH and host controls | Mesh identity plus SSH controls |
| Recovery | Provider console or alternate SSH path | Mesh recovery plus provider path |
| Main failure | Credential attack surface | Dependency or policy lockout |
What should a small team choose?
Choose tailnet-only when private access is available on every admin device, ACL ownership is clear, and a provider-console recovery route is documented. Keep a narrowly controlled public fallback when losing mesh access would otherwise stop incident response.
Do not remove public SSH until the private path has been exercised by more than one owner and the broken-SSH recovery plan is current. Compare identity operations with Tailscale SSH versus keys and treat a nonstandard port as noise reduction, not a boundary.