| ▲ | edentrey 5 hours ago |
| Tailscale is the only non-self-hosted part of my setup now and this has bugged me since. I use a custom Nameserver rule to point all my subdomains to a Caddy container sitting on my Tailnet. Caddy handles the SSL and routes everything to the right containers. I skipped Tailscale Funnel on purpose; since these are just family services, I’d rather keep them locked behind the VPN than open them up to the web.
This project looks promising as a replacement for my current setup and for its digital sovereignity of self hosting the server. I'm looking to manage several embedded devices remotely via Tailscale, but I've hit a major roadblock: the 90-day maximum expiration for Auth Keys. Constantly renewing these tokens is a significant maintenance burden, so I'm searching for a more permanent, 'set-and-forget' solution for my remote hardware. |
|
| ▲ | tass 5 hours ago | parent | next [-] |
| Tailscale allows you to disable the expiration time - I do this for my gateways. My other simplifier is having everything at home get a .home dns name, and telling Tailscale to route all these via tailnet. |
| |
| ▲ | edentrey 5 hours ago | parent [-] | | can you please tell me how to disable expiration time? I see auth keys have an Expiration which says it "Must be between 1 and 90 days."
I do use a custom domain name as well with a Nameservers rule to have all my services reachable as subdomains of my custom domain. | | |
| ▲ | aidos 4 hours ago | parent | next [-] | | You can create an oauth client that can generate keys as you need them. https://tailscale.com/kb/1215/oauth-clients#generating-long-... | |
| ▲ | 5 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | 4 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | matthewmacleod 4 hours ago | parent | prev [-] | | There is some confusion here because while you can disable node key expiration, you can’t disable auth key expiration. But that’s less of a problem than it seems - auth keys are only useful for adding new nodes, so long expiry times are probably not necessary outside of some specific use-cases. Edit: in fact from your original post it sounds like you’re trying to avoid re-issuing auth keys to embedded devices. You don’t need to do this; auth keys should ideally be single-use and are only required to add the node to the network. Once the device is registered, it does not need them any more - there is a per-device key. You can then choose to disable key expiration for that device. | | |
| ▲ | k_bx 3 hours ago | parent [-] | | I want my CI containers created per branch/PR to have their own Tailscale domain, so logging them in is useful via non-expiring key. Only good option I've seen previously is to notify every 90 days when key expires. | | |
| ▲ | matthewmacleod 3 hours ago | parent [-] | | The best way to do that is using an OAuth client. These don't expire, and grant scoped access to the Tailscale API. You use this to generate access keys for the devices that need to authenticate to the network. We use this for debugging access to CI builds, among other things – when a particular build parameter is set, then the CI build will use an OAuth key to request an ephemeral, single-use access key from the Tailscale API, then use that to create a node that engineers can SSH into. Access keys ideally should be short-lived and single-use where possible. https://tailscale.com/kb/1215/oauth-clients#generating-long-... has details on this flow. |
|
|
|
|
|
| ▲ | tecleandor 5 hours ago | parent | prev | next [-] |
| You can manually disable key expiration for hosts in Tailscale, and I think you can do it with tags too... https://tailscale.com/kb/1028/key-expiry#disabling-key-expir... |
| |
| ▲ | katdork 5 hours ago | parent [-] | | The word "auth keys" meant nothing to you, I guess: https://tailscale.com/kb/1085/auth-keys | | |
| ▲ | matthewmacleod 4 hours ago | parent [-] | | What would be your use-case for auth keys with long expiry times? Auth keys are only required for registering new nodes. | | |
| ▲ | stingraycharles 4 hours ago | parent [-] | | When managing your infrastructure as code, it’s quite common to deploy new instances for upgrades etc. Having these keys expire after 3 months is a big pain. Eg doing a routine update by rebuilding an AMI. I don’t understand how they can have such a strategy, and then not having any decent way to programmatically allocate new keys. | | |
|
|
|
|
| ▲ | inapis 4 hours ago | parent | prev | next [-] |
| Use tag-based node authentication. Login as a user and then switch the device to use a tag. I just recently did that and retained the usual 6 months expiry. I can also disable key expiry completely. |
|
| ▲ | atmosx 5 hours ago | parent | prev | next [-] |
| Headscale is a self hosted drop-in control plane replacement that has been pretty stable for us. |
|
| ▲ | Lucasoato 2 hours ago | parent | prev [-] |
| +1 for caddy in Tailnet, working well for us too! |
