5 ms·

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 co

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 8mo ago
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 8mo ago
  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.
  - deleted 8mo ago
    [deleted]
  - aidos 8mo ago
    You can create an oauth client that can generate keys as you need them. https://tailscale.com/kb/1215/oauth-clients#generating-long-lived-auth-keys https://tailscale.com/kb/1215/oauth-clients#generating-long-...
  - matthewmacleod 8mo ago
    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 8mo ago
      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 8mo ago
        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-lived-auth-keys https://tailscale.com/kb/1215/oauth-clients#generating-long-... has details on this flow.
        k_bx 8mo ago
        Thanks, I'll soon get to try this out hopefully!
  - deleted 8mo ago
    [deleted]
tecleandor 8mo ago
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-expiry https://tailscale.com/kb/1028/key-expiry#disabling-key-expir...
- katdork 8mo ago
  The word "auth keys" meant nothing to you, I guess: https://tailscale.com/kb/1085/auth-keys https://tailscale.com/kb/1085/auth-keys
  - matthewmacleod 8mo ago
    What would be your use-case for auth keys with long expiry times? Auth keys are only required for registering new nodes.
    - stingraycharles 8mo ago
      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.
      - matthewmacleod 8mo ago
        Yeah, that's a common workflow. It's easy to programatically allocate those keys using the OAuth workflow though – there's even a CLI utility to do it (https://tailscale.com/kb/1215/oauth-clients#get-authkey-utility https://tailscale.com/kb/1215/oauth-clients#get-authkey-util...) This can all be automated using e.g. the Terraform Tailscale provider, which takes the OAuth id/secret and can then issue keys as needed for the infrastructure you are deploying.
atmosx 8mo ago
Headscale is a self hosted drop-in control plane replacement that has been pretty stable for us.
inapis 8mo ago
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.
Lucasoato 8mo ago
+1 for caddy in Tailnet, working well for us too!
nagaiaida 8mo ago
you may also be interested in nebula (although you'd give up the nice management ui)

tass 8mo ago

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 8mo ago
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.
- deleted 8mo ago
  [deleted]
- aidos 8mo ago
  You can create an oauth client that can generate keys as you need them. https://tailscale.com/kb/1215/oauth-clients#generating-long-lived-auth-keys https://tailscale.com/kb/1215/oauth-clients#generating-long-...
- matthewmacleod 8mo ago
  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 8mo ago
    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 8mo ago
      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-lived-auth-keys https://tailscale.com/kb/1215/oauth-clients#generating-long-... has details on this flow.
      - k_bx 8mo ago
        Thanks, I'll soon get to try this out hopefully!
- deleted 8mo ago
  [deleted]

tecleandor 8mo ago

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-expiry https://tailscale.com/kb/1028/key-expiry#disabling-key-expir...

katdork 8mo ago
The word "auth keys" meant nothing to you, I guess: https://tailscale.com/kb/1085/auth-keys https://tailscale.com/kb/1085/auth-keys
- matthewmacleod 8mo ago
  What would be your use-case for auth keys with long expiry times? Auth keys are only required for registering new nodes.
  - stingraycharles 8mo ago
    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.
    - matthewmacleod 8mo ago
      Yeah, that's a common workflow. It's easy to programatically allocate those keys using the OAuth workflow though – there's even a CLI utility to do it (https://tailscale.com/kb/1215/oauth-clients#get-authkey-utility https://tailscale.com/kb/1215/oauth-clients#get-authkey-util...) This can all be automated using e.g. the Terraform Tailscale provider, which takes the OAuth id/secret and can then issue keys as needed for the infrastructure you are deploying.

atmosx 8mo ago

Headscale is a self hosted drop-in control plane replacement that has been pretty stable for us.

inapis 8mo ago

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.

Lucasoato 8mo ago

+1 for caddy in Tailnet, working well for us too!

nagaiaida 8mo ago

you may also be interested in nebula (although you'd give up the nice management ui)