Start with what the install actually does. `curl -fsSL https://tailscale.com/install.sh | sh` and then `sudo tailscale up` prints a URL; you sign in, and the machine joins the tailnet [17]. Transport is WireGuard, and the address `tailscale ip -4` hands back is a 100.x that only your other devices can route to [1][2]. sshd is unchanged and so are your keys. What changes is which interface a packet has to arrive on to get an answer [3].
The expiry default is where I would spend review time. At 180 days Tailscale logs the machine out and asks it to sign in again [5]. That sign-in is a browser flow driven from a shell on the machine, which is the thing you no longer have once the tailnet is the only door [6]. Divide a year by the default and you get 365/180, a bit over two of these events per machine per year, and each one lands on the anniversary of whatever provisioning date started the clock, a date that usually goes unrecorded [1]. The dev.to guide's mitigation is the per-machine Disable key expiry item in the Machines list, applied when you add the box rather than when you remember [7].
If verifying a closed port by behaviour rather than by config bothers you, the guide offers the stricter option: add `ListenAddress` lines for the Tailscale and loopback addresses to an sshd drop-in, so sshd never binds the public interface at all [18]. That moves the policy into two places instead of one, and pins a tailnet-assigned address into a config file. I would rather have a single rule set that says deny, and check it by trying to connect.
This recipe transfers under a few ordinary conditions. You need an out-of-band console from the provider, because it is the only recovery path here that does not run over the network you just made mandatory [11]. You need few enough machines that a manual per-machine toggle is real work someone does, not a step that quietly gets skipped. And you need to settle the authentication question on purpose: plain OpenSSH over the private address keeps your existing keys and hardening in force, which is what the author recommends for most people, while `sudo tailscale set --ssh` puts the daemon on port 22 of the tailnet address and authenticates against Tailscale identity and access rules [4][12]. The author treats that as a live disagreement rather than a settled answer, and frames the choice as how much you want to lean on one provider [13].
Ordering is the cheap insurance: bring up the new path, use it, then remove the old rule [14]. It is one line in the guide and the whole difference between a change and an incident.
