starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Windows tailscale client - NodeKey regeneration not supported #287

New Issue
Closed
opened 2025-12-29 01:26:12 +01:00 by adam · 2 comments
adam commented 2025-12-29 01:26:12 +01:00
Owner
Copy Link

Originally created by @daramos on GitHub (Jul 6, 2022).

Bug description
It seems that the Windows version of tailscaled generates a new NodeKey whenever the --login-server parameter is passed to tailscale up (only tested when running with unattended mode). Because of this the machine is stuck in a perpetual loop of requiring authentication.
This also causes endless headscale log entries of Machine registration has expired. Sending a authurl to register machine=*machine name*

I believe the issue is that when an existing machine key is passed to the RegistrationHandler but the NodeKey is completely new - the logic always falls down to the "Machine Expired" logic. ffcc72876c/api.go (L227-L260)

The machine expired logic sends the client an auth URL to re-authenticate. Unfortunately - even after re-authentication is successful, the NodeKey is never updated in headscale. Therefore, the client continues to fall through into the "Machine Expired" logic in the RegistrationHandler.

I'm not sure the proper way to fix this - I think the easiest way would be to update the NodeKey on re-authentication but I'm not sure the security implications of that.

The only workaround to resolve this is to do a headscale nodes delete on the affected node.

To Reproduce
(All these steps are on windows)

  1. tailscale up --login-server headscale url --unattended
  2. tailscale down
  3. tailscale up --login-server headscale url --unattended
  4. Follow the provided auth url to re-authenticate

At this point after re-authenticating you will observe the following:

  1. You will get a successful "Reauthenticated as user, you can now close this window. " message if you use oidc auth.
  2. tailscale client is still awaiting authentication.
  3. The headscale logs will be flooded with DBG Machine registration has expired. Sending a authurl to register machine=*machineName* messages
  4. The log in for tailscaled will contain the line 2022-07-06T16:21:02.039-04:00: control: Generating a new nodekey.
  5. Attempting to run tailscale logout returns 500 Internal Server Error: no nodekey to log out
  6. Running headscale nodes list will output that the affected machine is actually not expired.

Context info
Headscale Version: v0.16.0-beta5
Tailscale Version: 1.26.1

Originally created by @daramos on GitHub (Jul 6, 2022). **Bug description** It seems that the Windows version of tailscaled generates a new NodeKey whenever the `--login-server` parameter is passed to `tailscale up` (only tested when running with unattended mode). Because of this the machine is stuck in a perpetual loop of requiring authentication. This also causes endless headscale log entries of `Machine registration has expired. Sending a authurl to register machine=*machine name*` I believe the issue is that when an existing machine key is passed to the RegistrationHandler but the NodeKey is completely new - the logic always falls down to the "Machine Expired" logic. https://github.com/juanfont/headscale/blob/ffcc72876c63ed134ad111752a3523350e53250c/api.go#L227-L260 The machine expired logic sends the client an auth URL to re-authenticate. Unfortunately - even after re-authentication is successful, the NodeKey is never updated in headscale. Therefore, the client continues to fall through into the "Machine Expired" logic in the RegistrationHandler. I'm not sure the proper way to fix this - I think the easiest way would be to update the NodeKey on re-authentication but I'm not sure the security implications of that. The only workaround to resolve this is to do a `headscale nodes delete` on the affected node. **To Reproduce** (All these steps are on windows) 1. tailscale up --login-server *headscale url* --unattended 2. tailscale down 3. tailscale up --login-server *headscale url* --unattended 4. Follow the provided auth url to re-authenticate At this point after re-authenticating you will observe the following: 1. You will get a successful "Reauthenticated as *user*, you can now close this window. " message if you use oidc auth. 2. tailscale client is still awaiting authentication. 3. The headscale logs will be flooded with `DBG Machine registration has expired. Sending a authurl to register machine=*machineName*` messages 4. The log in for tailscaled will contain the line `2022-07-06T16:21:02.039-04:00: control: Generating a new nodekey.` 5. Attempting to run `tailscale logout` returns `500 Internal Server Error: no nodekey to log out` 6. Running `headscale nodes list` will output that the affected machine is actually not expired. **Context info** Headscale Version: [v0.16.0-beta5](https://github.com/juanfont/headscale/releases/tag/v0.16.0-beta5) Tailscale Version: 1.26.1
adam added the bug label 2025-12-29 01:26:12 +01:00
adam closed this issue 2025-12-29 01:26:12 +01:00
adam commented 2025-12-29 01:26:12 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Sep 8, 2022):

Hi, I had this issue on windows when passing the login server to the CLI as well and I "fixed" it by setting the registry key for the login server and then using the UI to log in. You can go to /windows on your headscale server to get instruction on how to set them.

That said, we should try to tackle this. There has been some changes to NodeKey and MachineKeys in the newest alpha (0.17.0) release, could you try that and verify if it still is the case?

@kradalby commented on GitHub (Sep 8, 2022): Hi, I had this issue on windows when passing the login server to the CLI as well and I "fixed" it by setting the registry key for the login server and then using the UI to log in. You can go to `/windows` on your headscale server to get instruction on how to set them. That said, we should try to tackle this. There has been some changes to NodeKey and MachineKeys in the newest alpha (0.17.0) release, could you try that and verify if it still is the case?
adam commented 2025-12-29 01:26:13 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Oct 28, 2022):

Closing due to inactivity, please try the latest version (including alpha), and see if it still the case and reopen.

@kradalby commented on GitHub (Oct 28, 2022): Closing due to inactivity, please try the latest version (including alpha), and see if it still the case and reopen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#287
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?