How to have a reusable preauth key that does not expire? #558

Closed
opened 2025-12-29 02:20:17 +01:00 by adam · 7 comments
Owner

Originally created by @bfontaine on GitHub (Sep 19, 2023).

Why

I need to have access to the VPN from a CI container on Gitlab in order to install packages from a private registry. In order to do so, I created a dedicated node and a reusable preauth key for ephemeral nodes:

headscale --user ci-node preauthkeys create --ephemeral --reusable --tags tag:ci

The CI node installs Tailscale then uses the key to connect:

tailscale up --authkey="${TAILSCALE_AUTH_KEY}" --hostname="ci-$(cat /etc/hostname)" --login-server="${TAILSCALE_LOGIN_SERVER}" --accept-routes --timeout 15s

(where TAILSCALE_AUTH_KEY is the preauth key and TAILSCALE_LOGIN_SERVER the headscale host)

However the preauth key I created earlier did expire at some point. I don’t see any option to disable this; if I don’t pass --expiration ... it defaults to 1h.

Description

A flag on the preauthkeys create command to create a preauth key that does not expire.

Originally created by @bfontaine on GitHub (Sep 19, 2023). ## Why I need to have access to the VPN from a CI container on Gitlab in order to install packages from a private registry. In order to do so, I created a dedicated node and a reusable preauth key for ephemeral nodes: ```bash headscale --user ci-node preauthkeys create --ephemeral --reusable --tags tag:ci ``` The CI node installs Tailscale then uses the key to connect: ```bash tailscale up --authkey="${TAILSCALE_AUTH_KEY}" --hostname="ci-$(cat /etc/hostname)" --login-server="${TAILSCALE_LOGIN_SERVER}" --accept-routes --timeout 15s ``` (where `TAILSCALE_AUTH_KEY` is the preauth key and `TAILSCALE_LOGIN_SERVER` the headscale host) However the preauth key I created earlier did expire at some point. I don’t see any option to disable this; if I don’t pass `--expiration ...` it defaults to 1h. ## Description A flag on the `preauthkeys create` command to create a preauth key that does not expire.
adam added the enhancement label 2025-12-29 02:20:17 +01:00
adam closed this issue 2025-12-29 02:20:17 +01:00
Author
Owner

@kradalby commented on GitHub (Sep 24, 2023):

You cannot, what you should do is programatically create new keys with the API or CLI tool as you need them.

Please also refer support issues to Discord and not the issue tracker. Thank you.

@kradalby commented on GitHub (Sep 24, 2023): You cannot, what you should do is programatically create new keys with the API or CLI tool as you need them. Please also refer support issues to Discord and not the issue tracker. Thank you.
Author
Owner

@comminutus commented on GitHub (Jan 23, 2024):

I'd like to see support for this. Creating new keys for ephemeral services after expiration seems tedious, especially if there are a good amount of them.

@comminutus commented on GitHub (Jan 23, 2024): I'd like to see support for this. Creating new keys for ephemeral services after expiration seems tedious, especially if there are a good amount of them.
Author
Owner

@quantumdecoherence commented on GitHub (Jan 29, 2024):

+1 for this issue. Enforcing password rotation is rather 2000's security, and generates a tedious amount of work for larger deployments.

@quantumdecoherence commented on GitHub (Jan 29, 2024): +1 for this issue. Enforcing password rotation is rather 2000's security, and generates a tedious amount of work for larger deployments.
Author
Owner

@martijnboers commented on GitHub (Mar 27, 2024):

At least having the option to disable it would be nice

@martijnboers commented on GitHub (Mar 27, 2024): At least having the option to disable it would be nice
Author
Owner

@fluential commented on GitHub (Apr 12, 2024):

We need non expiring keys

@fluential commented on GitHub (Apr 12, 2024): We need non expiring keys
Author
Owner

@travisghansen commented on GitHub (Apr 17, 2024):

Does it not work to simply set the expiry to 99y? I've done this and it shows up correctly as expiring well into the future but not sure if something else would cause an issue there as I'm new to tailscale and headscale.

@travisghansen commented on GitHub (Apr 17, 2024): Does it not work to simply set the expiry to `99y`? I've done this and it shows up correctly as expiring well into the future but not sure if something else would cause an issue there as I'm new to tailscale and headscale.
Author
Owner

@C-Duv commented on GitHub (Jan 27, 2025):

Setting a far expiration date is possible, but non-reusable token is blocking when an headless/unattended server/node has restarted and needs to re-connect to the tailnet no?

@C-Duv commented on GitHub (Jan 27, 2025): Setting a far expiration date is possible, but non-reusable token is blocking when an headless/unattended server/node has restarted and needs to re-connect to the tailnet no?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#558