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

Print nodes in registration cache #580

New Issue
Closed
opened 2025-12-29 02:20:44 +01:00 by adam · 6 comments
adam commented 2025-12-29 02:20:44 +01:00
Owner
Copy Link

Originally created by @paladincorners on GitHub (Nov 17, 2023).

Why

Currently in order to register a new node you have to manually type in a long node key, where it is easy to miss a character. Copy / paste may not be always possible. If you could print the nodes and their node keys in the registration cache, you could simply find the right node key and register it from the CLI. Additionally, this has a security benefit where you could check outstanding registration requests on your network and monitor if there are any unusual unauthorized attempts.

Description

Add a feature to print the node registration requests in the registration cache. Similar to how you have headscale nodes list you could do something like:

headscale regcache list

Or:

headscale regcache print
Originally created by @paladincorners on GitHub (Nov 17, 2023). <!-- We typically have a clear roadmap for what we want to improve and reserve the right to close feature requests that does not fit in the roadmap, or fit with the scope of the project, or we actually want to implement ourselves. Headscale is a multinational community across the globe. Our language is English. All bug reports needs to be in English. --> ## Why <!-- Include the reason, why you would need the feature. E.g. what problem does it solve? Or which workflow is currently frustrating and will be improved by this? --> Currently in order to register a new node you have to manually type in a long node key, where it is easy to miss a character. Copy / paste may not be always possible. If you could print the nodes and their node keys in the registration cache, you could simply find the right node key and register it from the CLI. Additionally, this has a security benefit where you could check outstanding registration requests on your network and monitor if there are any unusual unauthorized attempts. ## Description <!-- A clear and precise description of what new or changed feature you want. --> Add a feature to print the node registration requests in the registration cache. Similar to how you have `headscale nodes list` you could do something like: ``` headscale regcache list ``` Or: ``` headscale regcache print ```
adam added the enhancementstale labels 2025-12-29 02:20:44 +01:00
adam closed this issue 2025-12-29 02:20:44 +01:00
adam commented 2025-12-29 02:20:44 +01:00
Author
Owner
Copy Link

@vegardx commented on GitHub (Nov 17, 2023):

Have you looked at headscale preauthkeys?

@vegardx commented on GitHub (Nov 17, 2023): Have you looked at `headscale preauthkeys`?
adam commented 2025-12-29 02:20:45 +01:00
Author
Owner
Copy Link

@paladincorners commented on GitHub (Nov 17, 2023):

Hi! Yes I have, however for the authentication aspect, preauthkeys:

  1. Require using the terminal to register the node on a computer (on a Mac for example you can now register a node with Headscale using only the GUI)
  2. Are not supported on iOS at all
  3. Still have the same issue, but in reverse - getting the preauthkey to your end user and explaining to them how to use it

Aditionally, there is still the benefit of monitoring registration attempts to your instance.

@paladincorners commented on GitHub (Nov 17, 2023): Hi! Yes I have, however for the authentication aspect, preauthkeys: 1. Require using the terminal to register the node on a computer (on a Mac for example you can now register a node with Headscale using only the GUI) 2. Are not supported on iOS at all 3. Still have the same issue, but in reverse - getting the preauthkey to your end user and explaining to them how to use it Aditionally, there is still the benefit of monitoring registration attempts to your instance.
adam commented 2025-12-29 02:20:45 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 16, 2024):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Feb 16, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:20:45 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 24, 2024):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Feb 24, 2024): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 02:20:46 +01:00
Author
Owner
Copy Link

@kha84 commented on GitHub (Oct 31, 2025):

I recently came across a wierd issue with my several different headscale installations. I couldn't attach any new nodes to it:

  • on a client side I was running tailscale up --login-server https://myserver:444 (yes, I'm running it on a non-standard port)
  • tailscale was printing out the URL to follow like https://myserver:444/register/xxxx
  • but the built-in headscale web server wasn't responding on that URL (even after a restart)
  • I even tried to manually accept the node registration by running headscale nodes register --user some-new-user --key xxxx, but it was giving me an error could not register node: node not found in registration cache (again, the restart of headscale didn't help)

I eventually managed to work this around by adding a node with using preauthkey, but I totally get @paladincorners pain - having no way to see what keys are currently in the cache of headscale is limiting debugging / troubleshooting options. It would be great, if dev team could add this feature.

@kha84 commented on GitHub (Oct 31, 2025): I recently came across a wierd issue with my several different headscale installations. I couldn't attach any new nodes to it: - on a client side I was running `tailscale up --login-server https://myserver:444` (yes, I'm running it on a non-standard port) - `tailscale` was printing out the URL to follow like `https://myserver:444/register/xxxx` - but the built-in headscale web server wasn't responding on that URL (even after a restart) - I even tried to manually accept the node registration by running `headscale nodes register --user some-new-user --key xxxx`, but it was giving me an error `could not register node: node not found in registration cache` (again, the restart of headscale didn't help) I eventually managed **to work this around** by adding a node with using `preauthkey`, but I totally get @paladincorners pain - having no way to see what keys are currently in the cache of headscale is limiting debugging / troubleshooting options. It would be great, if dev team could add this feature.
adam commented 2025-12-29 02:20:46 +01:00
Author
Owner
Copy Link

@ykhrustalev commented on GitHub (Nov 14, 2025):

it would be a useful feature

@ykhrustalev commented on GitHub (Nov 14, 2025): it would be a useful feature
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 enhancement stale
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#580
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?