Tailscale SSH

> (SSH certificates are better, but have you tried running your own enterprise CA?)

For a small business, what is so hard about keeping a file (CA private key) secure and changing it when required?

What would be the advantages of this compared to say Teleport ?

Teleport is working fine for us, but I wonder if the network based approach (+ wireguard) of Tailscale would be better in terms of network redundancy ?

I edited the original to contain more detail as I posted it but it seems to have been lost somehow. The login flow for Tailscale is weird due to the need to accommodate things like a headless server being added, when combined with their use of SSO as the only method of authentication things get confused very easily.

When I add a new server I get given a URL that looks like https://login.tailscale.com/a/c44a243b to visit in a browser and authenticate the new device, the meaning of which is quickly lost as soon as you go through a Google Authenticator sign in flow, fill out some recaptchas and find your phone for a SMS token, and then the device is added to your account with no further clicks (unless you enable device authorization). It feels very weak, the connection between logging in and performing an action is fuzzy.

Due to the use of Google SSO it just has the usual problems that you get. It's not quite clear when you're logged in or not or with which of the 12 google accounts you own, it's not clear what will pop 2FA requests or login prompts. As a service tailscale has made it clear that they don't want to be an "identity provider", which means you're sort of stuck with something that doesn't feel like you can make authoritative decisions about how it acts.

We just adopted it to consolidate multiple different OpenVPN installations.

Why?

* The Tailscale clients are dead simple and good quality (but not perfect). OpenVPN clients for mac and iOS are pretty bad. Onboarding OpenVPN users was a large document that generated a lot of questions and support issues. Tailscale onboarding is about two minutes for most users and we had nearly no support requests rolling it out widely to our company.

* Tying OpenVPN to Okta is a truly terrible experience. Users would login with their Okta creds and a push would silently go to their devices. If they didn't know to check their phone it would just fail to login. Alternatively you can paste your TOTP code after your password. Yes, really.

* We don't have to manage or debug anything related to LDAP.

* Maintenance on our side is extremely minimal. Just install subnet routers (* We no longer have to tell users to logout and login to another VPN to get to certain resources. We just grant them access and suddenly they can reach what they need. ACLs are amazing and super easy to script, audit, and test.

* Split DNS that actually works on all operating systems. For private domain A, query this resolver (over the wireguard link), for private domain B, query this other resolver.

* I rolled it out as a PoC to all of our major VPCs in a day.

The bad? It's still a young product and is missing features and has some warts.

* Notifications on macOS that you need to relogin are just plain broken (they know and are working on it).

* We're currently battling issues with network resets due to what looks like a client bug when you have lots of users.

* No access to audit logs yet

* You can't restrict people from using exit nodes

* No good way to canary changes to your user population. Any mistake in the UI instantly breaks everyone.

This is correct.

One answer is to have many, many SSO/IDP systems -- and for anyone technical enough to set up a homelab to be able to be their own IDP.