Connect a Linux server

The second node will be a disposable Ubuntu or Debian server. Keep its existing recovery access until the private path is tested.

That last sentence is the rule I want you to internalize. Never cut off the current way in before the new way is proven. If your only access today is SSH over the public address, keep that session open through this whole lesson.

Install and authenticate

Use Tailscale’s official installer or the documented package repository, then run tailscale up:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

The command prints a browser authentication URL:

To authenticate, visit:

	https://login.tailscale.com/a/1b2c3d4e5f6a7

Open it from your laptop, approve the device, and the command returns. After approval, the server appears in the same tailnet without requiring an inbound Tailscale port on the server firewall. The client opened an outbound connection to the coordination server. Nothing new was exposed publicly.

Verify from both sides

On the server:

tailscale status

100.101.9.23   lab-server   flavio@   linux   -
100.87.12.44   flavio-mbp   flavio@   macOS   active; direct 93.44.120.15:41641

Confirm the server appears in the admin console too, owned by your user and recently seen. Then, from your laptop, test the private path while the old session stays open:

ssh [email protected]

Keep the original SSH session open while testing the new private route. If the tailnet connection works, you now have two independent paths to the machine. If routing or policy breaks something later, the public session is your recovery path.

One common surprise: a strict host firewall can block the new path. Tailscale traffic arrives on the tailscale0 interface, so a ufw ruleset that only allows the public SSH port will reject SSH over the tailnet IP until you allow it on that interface.