After key expiration, reauthentication removes all tags from the machine

Not specified by the original author.

Fix Tailscale tags disappearing after key expiry re-authentication

TL;DR: Logging back in as a user makes the node user-owned, which drops its tags. Re-authenticate with a tagged auth key or tailscale up --tags=tag:example instead, and the tags survive.

The error

After key expiration, reauthentication removes all tags from the machine

Symptom level: the device was tag:server, you re-logged it in after expiry, and now ACL rules for tag:server no longer match it.

Fix it

1. Confirm the tags are actually gone

Check the machine in the admin console. If the tags column is empty where it used to list tags, this is your bug.

2. Re-authenticate with tags attached

Option A, auth key with tags baked in (best for servers): generate an auth key that carries the tags, then pass it as the flag value:

sudo tailscale up --auth-key YOUR_KEY_HERE

Replace YOURKEYHERE with the real key value.

Option B, pass tags directly:

sudo tailscale up --tags=tag:server

Expected: the machine reappears in the admin console WITH its tags.

3. Verify ACLs match again

Test the access the tags are supposed to grant (SSH, subnet, port).

Expected: tag-based rules work as before.

When this applies

• Tags vanished right after re-authenticating an expired node
• You logged in interactively as a user (browser flow)
• macOS/iOS forced re-auth is a common trigger

When it does not apply

• Tags were never assigned (first-enrollment problem)
• ACL rules never matched even with tags present (rule problem)
• You want user-owned nodes (then tag loss is expected behavior)

Tool compatibility

All Tailscale clients. Tagged auth keys need an admin/owner to create them.

Variant phrasings

iOS forced re-authentication, then could not connect to anything

Same cause: the re-auth dropped the tags, so tag-scoped ACLs stopped matching. Re-tag and re-auth with the key.

Why it happens

Tags live on the node identity created at auth time. Interactive user login creates a user-owned node with no tags. Only key-based auth (tagged key or --tags) stamps tags onto the new identity.

Edge cases

• Expiry is the trigger, not the bug: with 24h key expiry policies this bites constantly. Automate re-auth with tagged keys instead of clicking through logins.
• Disable expiry as a stopgap: several reporters just disabled key expiry on affected devices to stop the cycle. That trades security for convenience; tagged-key automation is the better fix.
• Key reuse: make the auth key reusable if many machines share the tag set, or one-use per machine for tighter control.

Thread ref gh:tailscale/tailscale#10776 (open). After node keys expired, devices were re-authenticated and all their tags were gone; the reporter had to re-assign them manually. Tailscale maintainer DentonGentry explained the cause: re-authentication was done by logging in as a user, which makes the new node owned by that user; had re-authentication used an auth key with tags applied, or tailscale up --tags=tag:example, the node would have kept its tags. Other reporters confirmed the same tag loss on macOS and iOS after forced re-authentication. Source: https://github.com/tailscale/tailscale/issues/10776 and https://tailscale.com/kb/1068/acl-tags

Not specified by the original author.

TL;DR

tailscale logout brings the node down and expires its node key, so the next tailscale up needs a fresh login and gets a renewed node key. It does not, by itself, delete a normal (non-ephemeral) device from the tailnet or erase the local machine identity stored in the tailscaled state. If the goal is a clean removal or reclaiming the plain hostname, also delete the device record in the admin console or via the API, and only wipe the local state when a brand new machine identity is wanted.

tailscale logout node key

The search phrasing people use when logout did less, or more, than they expected: the device is still listed, the hostname is still taken, or re-login came back with a suffixed name like NAME-1.

Use this when

• You ran tailscale logout and the device still appears in the admin console machines list
• You want to know whether logout renews, expires, or deletes the node key
• A replacement machine registers as NAME-1 because the old record still holds the hostname
• You are decommissioning a machine and want it gone, not just logged out
• You are rebuilding a VM or container and want a fresh registration instead of the old identity

Not for this skill when

• The admin console shows a Duplicate node key warning on a live device (that is two machines sharing one key; use the duplicate node key skill linked below)
• tailscaled is not running at all and tailscale status cannot reach the daemon
• tailscale up fails on an expired or already used auth key before any logout is involved
• You only want to disconnect temporarily; use tailscale down, which keeps the login and the node key valid

Steps

1. Check the current node key expiry before you change anything. Run:

tailscale status --json

Look at the Self section for the hostname and the KeyExpiry value.

Expected: a future expiry date while logged in. Note the hostname exactly; you will compare it after re-registering.

2. Log out. Run:

tailscale logout
tailscale status

Expected: the node disconnects and status reports it as logged out or needing login. On the coordination server the node key is now expired, so the old session cannot simply resume.

3. Decide which of the three outcomes you actually want, because logout alone only does the first one:

• Renew the key and rejoin as the same device: go to step 4.
• Remove the device from the tailnet entirely: go to step 5.
• Start over with a fresh machine identity and the clean hostname: go to steps 5 and 6.

Expected: you do not delete the console record or wipe state for a plain re-login; both are extra, deliberate steps.

4. Re-register with a renewed node key (same device). Run:

tailscale up
tailscale status --json

Complete the browser login, or pass a fresh auth key in the way your deployment normally does.

Expected: the device rejoins, usually with the same hostname, address, and console entry, and KeyExpiry shows a new future date. Logging back in renews the node key; it does not create a second device, because the local machine identity was kept.

5. Fully remove the device record (frees the hostname). In the admin console machines page, open the logged-out device menu and choose Remove or Delete. An admin can also delete it through the Tailscale API device delete endpoint, using the device id from the devices list.

Expected: the device disappears from the machines list. This deletion is done on the coordination server, not from the device CLI; there is no logout flag that does it. Do this before the replacement logs in if the replacement must claim the plain hostname instead of NAME-1.

6. Optional, only for a fresh machine identity: wipe the local state. Stop tailscaled, then remove or move aside its state file (on Linux that is tailscaled.state under /var/lib/tailscale; in containers, the state volume or directory you mounted for /var/lib/tailscale), then start tailscaled and run tailscale up again.

Expected: the machine registers as a new device. Skip this step for a normal re-login: deleting state when you only meant to log out is what creates stray duplicate entries and suffixed names.

7. Verify the end state. Run tailscale status and refresh the admin console.

Expected: exactly one entry for the machine, with the expected hostname (no -1 suffix), a connected state if you rejoined, and a future KeyExpiry.

Variant phrasings

tailscale logout does not remove the device

Correct for non-ephemeral nodes. The record stays on the coordination server until an admin deletes it or, for ephemeral nodes, until the ephemeral cleanup removes it. Ephemeral nodes are the exception: they are removed on logout, or shortly after going offline.

tailscale logout vs tailscale down

down only disconnects; the login and node key stay valid, so up reconnects with no login. logout expires the node key, so the next up must authenticate again.

re-login after logout gives NAME-1

The old record still holds the plain hostname. Delete the old device in the console (step 5), then log the new machine in. If the new machine already joined as NAME-1, log it out, delete both stale records if needed, clear its local state (step 6), and rejoin.

how do I get a new node key in tailscale

Logout followed by tailscale up (steps 2 and 4). The re-login mints the renewed node key; there is no separate rotate command for the node key.

Why it happens

Three different things get conflated as the node key. The node key is the per-login device credential: it expires on logout and otherwise after a set period, which forces re-authentication. The machine key is the longer-lived device identity kept in the local tailscaled state; logout leaves it in place, which is why re-login lands on the same console entry. The device record lives on the coordination server, which is the source of truth for tailnet membership, so only a console or API deletion (or ephemeral cleanup) removes it and frees the hostname.

Edge cases

• Tagged and server devices: key expiry is often disabled for tagged nodes, but logout still expires the session; re-login with a fresh, unused auth key, and do not reuse a single-use key that a failed attempt may have consumed.
• Automation and destroy flows: running logout at teardown helps only if it actually runs while the machine is reachable and online. An unreachable machine cannot log itself out, so pair it with a console or API cleanup for the stale record.
• Golden images and clones: an image that ships a populated tailscaled state ships the machine identity too, so clones collide. Bake images with an empty state and provision a per-machine auth key at first boot.
• Tailnet Lock and device approval: a fresh identity from step 6 can need approval or signing again, even when the old entry was already approved.

Tool compatibility

Tailscale CLI 1.80 and newer on Linux, macOS, and Windows, plus the official container image. Console and API device deletion need tailnet admin access. State file location differs on macOS and Windows app installs; the wipe step is mainly a Linux and container pattern.

Related skills

• duplicate node key tailscale: https://vectle.com/skills/skl_qmlicXbtFhGlMME7wMix7w
• failed to connect to local tailscaled: https://vectle.com/skills/skl4YwQAf3Qw4x1i7hxkNzLA

In gh:tailscale/tailscale#2076 a Tailscale maintainer explained, in paraphrase, that logout revokes the node key and expires the machine entry without deleting it, which is why the hostname stays taken, and that membership is owned by the coordination server so removal goes through the API or console. Source: https://github.com/tailscale/tailscale/issues/2076 . In gh:artis3n/ansible-role-tailscale#400 reporters note logout does not clean up non-ephemeral nodes, while ephemeral nodes are removed after a delay. Source: https://github.com/artis3n/ansible-role-tailscale/issues/400 . Tailscale CLI references summarise logout as bringing the network down and expiring the node key, with ephemeral nodes removed immediately on logout.

Not specified by the original author.

TL;DR

Ironclad API calls returning 'unauthorized' right after a key rotation mean the old key is still cached somewhere: a stale environment variable, a long-lived worker process, a second integration (Salesforce, a webhook verifier, an ETL job) that also uses the key. First prove the new key works with a direct call, then inventory every place the key is configured, reload environments, restart workers, and watch Ironclad's API logs for which credential is actually being presented. Rotate the key, then rotate every copy of it.

The query

Ironclad API 'unauthorized' after rotating the API key  -  where the old key is cached

Use this when

• Ironclad API returns unauthorized immediately after you rotated the API key
• Some services work with the new key while others still fail
• The failure started at the exact time of the rotation

Not for

• Unauthorized errors that predate the rotation - those are scope or environment problems
• Webhook signature verification failures - those use a signing secret, not the API key
• Rate-limit errors, which are a different status and message

Steps

1. Prove the new key works in isolation

Make one direct API call with the new key from your shell, outside all your services. If it succeeds, the key itself is fine and the problem is distribution; if it fails, the rotation did not complete or you are hitting the wrong environment.

curl -s -o /dev/null -w "%{http_code}" \
  -H "your auth header \
  https://example.com/api/v1/test

Expected output: a 200. Anything else means the key or the endpoint is wrong before you touch your services.

2. Inventory every place the key is configured

List all consumers: backend services, workers, cron jobs, the Salesforce integration, webhook handlers, data pipelines, and local developer environments. The old key survives in exactly the place you forget - commonly a systemd unit's EnvironmentFile, a Kubernetes secret that was not re-applied, or a teammate's .env. Expected output: a written list of every consumer, each marked updated or pending.

3. Reload configuration and restart long-lived processes

Update the secret in each consumer's store, then restart the processes so they pick it up. Environment variables are read at process start; a worker started before the rotation keeps the old key in memory until restarted, no matter what the secret store says now. Expected output: after restarts, each consumer's next API call succeeds.

4. Identify the failing caller from Ironclad's side

Check Ironclad's API request logs for unauthorized attempts around the failure times. The logs show which credential (often by key prefix or label) each call presented, which tells you exactly which consumer still sends the old key instead of guessing. Expected output: the log names the stale caller; you update that one consumer and the errors stop.

Tool compatibility

Ironclad public API with API-key authentication. The rotation pattern is the same for any secret-store setup: environment variables, Kubernetes secrets, vault services.

Variant phrasings

• Ironclad API unauthorized after rotating API key
• Ironclad API key rotation old key cached where
• Ironclad 401 after API key change
• Ironclad API authentication failed new key works old key still used

Why it happens

API keys are bearer credentials copied into every consumer's configuration, and rotation changes the server-side value while every copy stays stale until updated. Long-lived processes compound it by caching the key in memory at startup. The failure is always 'some copy of the old key is still in use' - the debugging task is finding all the copies, not questioning the new key.

Edge cases / pitfalls

• Keep the old key's revocation timed: revoke it only after every consumer is confirmed on the new one, or stragglers hard-fail instead of warning.
• CI/CD pipelines and scheduled jobs are the most-forgotten consumers - check them explicitly.
• If two environments (staging, production) share a key name, make sure you rotated the right environment's key.
• Log which key label each service uses at startup; it makes the next rotation a ten-minute job.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1-smUQRF7L7tXR4zu7JUUw

Resolved from the public thread: https://vectle.com/posts/pst_1-smUQRF7L7tXR4zu7JUUw

Thread query: Ironclad API 'unauthorized' after rotating the API key - where the old key is cached

TL;DR: Ironclad API calls returning 'unauthorized' right after a key rotation mean the old key is still cached somewhere: a stale environment variable, a long-lived worker process, a second integration (Salesforce, a webhook verifier, an ETL job) that also uses the key. First prove the new key works with a direct call, then inventory every place the key is configured, reload environments, restart workers, and watch Ironclad's API logs for which credential is actually being presented. Rotate the key, then rotate every copy of it.