Reauthenticate a Remote Tailscale Device Safely

Forcing a new Tailscale login on a remote server can drop the tailnet connection before the device finishes signing back in. That is not a bug in the command; it is the operation working as designed on the path you are using. The rule is simple: arrange a second way to reach the machine before you renew its key. Everything else is preparation for that moment.

Why the command can cut you off

The device key is what lets the node join the tailnet. Renewing it means the old key stops being accepted, and the node must complete a fresh login before it can rejoin. If your only session runs over that tailnet, the rejoin happens without you. A subnet router makes this worse, because clients keep their routes and lose the path behind them.

That is why the order matters more than the command itself. Access first, renewal second. A console session, a serial console or a colleague on site all count.

Rule out a different fault first

Confirm the key is actually the problem before renewing anything. Check the admin console for expiry, then check the device's own status for whether it is connected and which peers it can see. A valid key with a broken route, an ACL change or a stopped service looks similar from a distance. Forced renewal repairs none of those.

tailscale status

If the node is online and the key is valid, keep looking. Renewal is a last resort, not a general repair. Read the peer list as well as the online flag, because a half-connected node still reports up.

Renew with a second way in

With console access or a second management path ready, run the renewal on the device. Tailscale documents the force-reauth form of the up command for this purpose, and it needs elevated privileges where the platform requires them. Run it once, and watch the output rather than closing the session. If the command drops your connection, reconnect through the second path and read the local log.

sudo tailscale up --force-reauth

If the key has already expired, the admin console may offer a temporary extension for eligible devices. That extension is a window to regain access and finish signing in, not a permanent substitute for it. Note the deadline it displays.

Test what the device actually serves

After the device rejoins, test the service it exists to provide. A router should be tested through a resource behind it, an exit node through the intended internet path, and a plain server through the port you actually use. A node showing online exercises none of those by itself. Test from a machine that is not the node, since local checks bypass the tailnet path entirely.

tailscale ping 100.101.102.103

Then write down the expiry policy for this machine. An unattended connector and a personal laptop have different tolerances, and the person who inherits the server should not have to rediscover which one it is. That note is the difference between a documented policy and a surprise next year. Tailscale's key expiry documentation covers the renewal options and their limits.