Clé Tailscale expirée : réparer un serveur headless

La réponse courte

Un serveur qui a rejoint Tailscale il y a six mois et qui disparaît du tailnet aujourd'hui, c'est presque toujours une clé Tailscale expirée. Par défaut, chaque machine doit se ré-authentifier tous les 180 jours. Un portable affiche une invite pour le faire. Un serveur headless, sans écran ni session graphique, ne montre rien à personne : le nœud sort simplement du réseau le jour de l'échéance.

La réparation immédiate tient en une commande, lancée depuis une session SSH sur l'adresse IP publique du serveur : sudo tailscale up --force-reauth, puis ouvrir dans un navigateur l'URL que la commande affiche. La réparation durable consiste à sortir le serveur de ce cycle : soit en désactivant l'expiration pour cette machine dans la console d'administration, soit, mieux, en le rattachant à un tag ACL, parce qu'un nœud tagué n'expire pas par défaut et ne dépend plus du compte d'une personne.

Étape 1 : reprendre la main sans le tailnet

Le premier réflexe est de se connecter en SSH par l'adresse Tailscale du serveur, en 100.x.y.z, et cela échoue. Le tunnel est justement ce qui est cassé, il faut donc un autre chemin.

Si le port 22 du serveur écoute encore sur l'adresse publique, une session classique suffit :

ssh admin@203.0.113.10

Si vous aviez limité sshd à l'interface Tailscale, ou fermé le port 22 dans le pare-feu du fournisseur, il reste la console série ou VNC du panneau de votre hébergeur. Notez-le pour plus tard : un serveur dont l'accès d'administration passe uniquement par le tailnet doit garder une porte de secours, et durcir SSH sur un VPS ne veut pas dire supprimer ce chemin. Si la connexion publique échoue aussi, la forme de l'échec vous dit déjà où chercher, voir la différence entre connection refused et connection timed out.

Gardez cette session ouverte jusqu'à la fin. Toutes les commandes qui suivent se lancent dedans.

Étape 2 : confirmer que c'est bien la clé

Avant de relancer quoi que ce soit, vérifiez que le service tourne et regardez ce qu'il dit :

systemctl status tailscaled --no-pager
tailscale status
sudo journalctl -u tailscaled -n 50 --no-pager

Sur un nœud dont la clé a expiré, tailscaled est actif : le processus n'a pas planté, il n'a juste plus le droit de parler au serveur de coordination avec sa clé actuelle. tailscale status ne montre plus le tableau des pairs avec leurs adresses ; il vous indique, en substance, que le nœud est déconnecté et doit se reconnecter. La sortie JSON est plus précise, et ses champs sont stables d'une version à l'autre :

sudo apt install -y jq
tailscale status --json | jq '{state: .BackendState, expiry: .Self.KeyExpiry, expired: .Self.Expired}'

BackendState vaut Running sur un nœud sain. Ici il prend une autre valeur, généralement NeedsLogin. Self.KeyExpiry est la date à laquelle la clé a expiré, et Self.Expired passe à true quand cette date est dépassée. Ces deux champs existent aussi pour chaque pair, ce qui servira plus bas.

Le même diagnostic existe depuis la console d'administration : sur la page Machines, la ligne du serveur signale la clé expirée à côté de son nom. Si elle affiche encore une date d'expiration future et que le nœud est hors ligne quand même, le problème est ailleurs : pare-feu ou service arrêté, pas la clé.

Étape 3 : ré-authentifier avec tailscale up --force-reauth

sudo tailscale up --force-reauth

La commande ne rend pas la main. Elle affiche une ligne To authenticate, visit: suivie d'une URL de la forme https://login.tailscale.com/a/.... Copiez cette URL dans le navigateur de votre poste de travail, pas sur le serveur. Connectez-vous avec le compte qui possède le tailnet, validez la machine, et la commande sur le serveur se termine d'elle-même : une nouvelle clé de nœud est générée et acceptée pour une nouvelle période.

Vérifiez tout de suite :

tailscale status
tailscale ip -4

tailscale status doit de nouveau lister vos autres machines, et tailscale ip -4 rend l'adresse 100.x.y.z d'origine : la ré-authentification conserve l'identité du nœud, donc son adresse et son nom. Depuis un autre nœud, un ping vers cette adresse répond, et votre connexion SSH par le tailnet fonctionne de nouveau.

Deux choses cassent souvent à cette étape.

Le message « changing settings via 'tailscale up' requires mentioning all non-default flags ». Il apparaît si le serveur avait été joint avec des options, par exemple --ssh ou --advertise-routes. tailscale up traite chaque appel comme la définition complète de la configuration, donc un appel nu voudrait dire « retirez ces options ». Il refuse plutôt que de deviner, et il imprime la commande complète avec les options actuelles. Copiez cette commande et ajoutez-lui --force-reauth :

sudo tailscale up --force-reauth --ssh --advertise-routes=10.0.0.0/24

N'utilisez --reset que si vous voulez vraiment repartir avec les valeurs par défaut. Sinon vous perdez Tailscale SSH ou vos routes annoncées au passage, et vous ne le découvrez qu'à la panne suivante.

Le mauvais compte dans le navigateur. L'URL d'authentification rattache le nœud au compte avec lequel vous vous connectez. Si votre navigateur est déjà connecté à un compte personnel alors que le serveur appartient au tailnet de votre société, le serveur atterrit dans le mauvais tailnet, avec une nouvelle identité, et vos autres machines ne le voient toujours pas. Utilisez une fenêtre de navigation privée et vérifiez le nom du tailnet en haut de la page avant de valider.

Un dernier point pratique : ne lancez jamais --force-reauth à travers une session SSH qui passe elle-même par le tailnet. L'aide de l'option le dit dans son propre texte : elle peut couper la connexion Tailscale. Quand la clé est déjà expirée, la question ne se pose pas. Mais si vous appliquez cette procédure par avance sur un serveur encore joignable, passez par l'adresse publique ou par la console.

Pourquoi la clé Tailscale a expiré, et pourquoi votre portable n'a pas ce problème

Chaque appareil d'un tailnet possède une clé de nœud, la paire de clés WireGuard que le serveur de coordination distribue aux autres membres. Cette clé a une durée de vie. Par défaut, un tailnet la fixe à 180 jours, et un administrateur peut la ramener entre 1 et 180 jours dans la page Device management de la console (vérifié le 17 septembre 2026 sur la page officielle sur l'expiration des clés). À l'échéance, le serveur de coordination cesse de considérer la clé comme valide : il ne la diffuse plus aux pairs, qui voient le nœud hors ligne, et il refuse au nœud lui-même la carte du réseau. WireGuard seul n'a pas ce mécanisme, une clé WireGuard ne périme jamais, et c'est l'une des vraies différences quand on compare WireGuard et Tailscale sur un serveur.

L'expiration existe pour une raison saine : une clé qu'un humain doit renouveler est une clé qu'un appareil perdu ou volé ne peut pas utiliser indéfiniment. Sur un portable, l'application Tailscale affiche une invite de reconnexion à l'approche de l'échéance, l'utilisateur clique, et personne ne s'en souvient. Sur un serveur sans interface graphique, personne ne reçoit d'invite, et le nœud sort du réseau exactement 180 jours après le jour où vous l'avez joint. Cette mécanique est conçue pour des appareils tenus par des personnes. Un serveur n'est pas tenu par une personne, et c'est pour cela que la réponse durable consiste à le déclarer comme tel.

Solution intermédiaire : désactiver l'expiration pour cette machine

Sur la page Machines de la console, ouvrez le menu à l'extrême droite de la ligne du serveur et choisissez « Disable key expiry ». La ligne indique ensuite que l'expiration est désactivée, et le même menu permet de la réactiver. Faites-le après la ré-authentification, pas avant : désactiver l'expiration ne ressuscite pas une clé déjà expirée, cela empêche seulement la prochaine.

C'est rapide et c'est mieux que rien, mais le nœud reste rattaché à votre compte utilisateur. Si ce compte est suspendu ou quitte l'organisation, le serveur part avec lui. Et chaque nouveau serveur réclame le même clic, que quelqu'un finira par oublier.

La bonne solution pour un serveur : un nœud tagué

Un tag est une étiquette ACL, tag:server par exemple, qui remplace le compte utilisateur comme identité du nœud. La documentation le dit sans détour : un appareil ne peut pas avoir à la fois un utilisateur et un tag. Deux conséquences vous intéressent. La première : quand un tag est appliqué à un appareil pour la première fois et que celui-ci est authentifié, l'expiration de clé est désactivée par défaut. La seconde : le nœud ne dépend plus de la connexion d'une personne, ce qui est exactement le comportement attendu d'un serveur.

Déclarer le tag dans la politique d'accès

Ouvrez l'éditeur de politique d'accès de la console, page Access controls, et ajoutez une section tagOwners. Elle nomme les personnes autorisées à poser ce tag :

{
  "tagOwners": {
    "tag:server": ["vous@example.com"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

La règle acls illustre le second changement : vos règles existantes, qui autorisaient l'accès vers ce serveur en tant que machine de vous@example.com, ne s'appliquent plus à un nœud tagué. Il faut des règles dont la destination est tag:server, sinon le nœud revient en ligne mais personne ne peut s'y connecter. Si vous utilisez Tailscale SSH, la section ssh de la politique a le même besoin.

Convertir le serveur existant

Le serveur est déjà ré-authentifié et en ligne. Relancez l'authentification en demandant le tag, toujours depuis la session sur l'adresse publique :

sudo tailscale up --force-reauth --advertise-tags=tag:server

Même flux qu'avant : une URL à ouvrir dans un navigateur, puis une validation. Le compte avec lequel vous vous connectez doit figurer dans tagOwners pour ce tag, ou être administrateur du tailnet, sinon la console refuse la validation. Une fois validé, la page Machines montre le nœud avec son tag à la place de votre adresse e-mail, et une mention indiquant que l'expiration est désactivée. La console permet aussi de poser le tag depuis le menu « Edit tags » de la machine ; dans ce cas, vérifiez ensuite sur la ligne que l'expiration est bien désactivée, et faites-le sinon depuis le même menu.

Joindre un nouveau serveur directement avec une clé d'authentification

Pour un serveur que vous installez aujourd'hui, ne passez pas par le flux navigateur du tout. Dans la console, page Settings puis Keys, choisissez « Generate auth key ». Activez l'option Tags et sélectionnez tag:server. Laissez la clé à usage unique sauf si vous enrôlez plusieurs machines. La clé elle-même a une durée de validité de 1 à 90 jours : c'est la période pendant laquelle elle peut servir à joindre une machine, pas la durée de vie du nœud. Une fois le serveur joint, la clé d'authentification peut expirer sans aucun effet sur lui.

Sur le serveur, mettez la clé dans un fichier plutôt que sur la ligne de commande, où elle finirait dans l'historique du shell. read -rs lit la clé sans l'afficher et sans l'enregistrer dans l'historique : collez-la, puis validez avec Entrée.

read -rs TSKEY
printf '%s\n' "$TSKEY" | sudo tee /root/tailscale-auth.key > /dev/null
sudo chmod 600 /root/tailscale-auth.key
sudo tailscale up --auth-key=file:/root/tailscale-auth.key
sudo rm /root/tailscale-auth.key
unset TSKEY

Aucune URL n'apparaît : la commande revient directement, tailscale status liste les pairs, et la console montre un nœud portant tag:server avec l'expiration désactivée dès le premier jour. C'est le flux à mettre dans vos scripts d'installation et dans cloud-init, parce qu'il ne demande rien à personne. La même logique vaut pour un routeur de sous-réseau Tailscale sur un VPS ou pour un nœud de sortie Tailscale : ce sont des serveurs, et ils ne devraient jamais dépendre d'un renouvellement manuel.

Tout cela renforce la sécurité plutôt que de l'affaiblir. Un tag remplace « quelqu'un s'est connecté il y a moins de 180 jours » par « cette machine a été déclarée comme serveur par une personne autorisée à le faire », ce qui est une affirmation plus précise. Pour comprendre ce que le serveur de coordination sait et ne sait pas de vos nœuds, lisez ce que Tailscale voit réellement de votre trafic.

L'état voisin : « logged out » après tailscale logout ou une réinstallation

Le symptôme ressemble, la cause est différente. sudo tailscale logout supprime la clé de nœud volontairement : le nœud n'a plus d'identité du tout, et le prochain tailscale up affiche de nouveau une URL d'authentification. Le nœud reste visible dans la console, mais aucun pair ne peut le joindre tant que quelqu'un n'a pas suivi cette URL.

Une réinstallation du système produit le même état par un autre chemin. L'identité du nœud vit dans /var/lib/tailscale/tailscaled.state. Après une réinstallation de l'OS puis de Tailscale, ce fichier n'existe plus : le serveur n'est pas « expiré », il est neuf. Quand vous le joignez, la console montre deux machines : l'ancienne, hors ligne pour toujours, et la nouvelle, avec un suffixe numérique dans son nom parce que l'ancien nom est encore pris. Supprimez l'ancienne entrée depuis son menu. La nouvelle machine reçoit une nouvelle adresse 100.x.y.z, ce qui casse toute configuration qui utilisait l'ancienne adresse en dur. Utilisez les noms MagicDNS plutôt que les adresses, pour cette raison précise.

Un tag rend ce cas simple : rejoignez la machine neuve avec une clé d'authentification taguée et vos règles ACL s'appliquent immédiatement, puisqu'elles visent tag:server et pas une machine précise. Si votre tailnet utilise tailnet lock, une machine neuve n'est pas encore signée et ne peut parler à personne tant qu'un nœud signataire ne l'a pas approuvée ; le fonctionnement est décrit dans le guide sur tailnet lock. Et si tailscale up échoue avant même d'afficher une URL, le problème est en amont, côté paquets ou dépôt, voir les erreurs d'installation de Tailscale sur Ubuntu.

Voir les dates d'expiration avant qu'elles ne frappent

La console d'administration affiche, pour chaque ligne de la page Machines, si l'expiration est désactivée ou quand elle tombe. Un tour de cette page par mois suffit pour un petit tailnet. Pour un tailnet avec plus de machines, ou pour qu'un script vous prévienne, chaque nœud connaît les dates de tous ses pairs :

tailscale status --json | jq -r '(.Self, .Peer[]) | [.HostName, (.KeyExpiry // "jamais"), (.Expired // false)] | @tsv'

La sortie donne une ligne par machine avec trois colonnes : le nom d'hôte, puis la date d'expiration en UTC (ou jamais si elle est désactivée), puis true si la clé est déjà expirée. KeyExpiry est absent du JSON quand l'expiration est désactivée, et Expired est absent tant que la clé est valide, d'où les valeurs de repli dans la commande. Mettez-la dans un cron hebdomadaire qui vous envoie un message quand une date tombe dans les quinze jours, et vous ne relirez jamais ce guide en urgence. Sur un tailnet bien tenu, la colonne du milieu ne contient que jamais pour tout ce qui est un serveur.

FAQ

Pourquoi mon serveur Tailscale apparaît hors ligne alors que tailscaled tourne ?

Parce que sa clé de nœud a expiré. tailscaled est actif, mais le serveur de coordination ne distribue plus sa clé aux autres membres du tailnet, qui le voient hors ligne, et lui refuse la carte du réseau. tailscale status --json montre Self.Expired à true et un BackendState différent de Running. La réparation est sudo tailscale up --force-reauth depuis une session sur l'adresse publique, puis l'URL affichée ouverte dans un navigateur.

Puis-je lancer tailscale up --force-reauth à travers le tailnet ?

Non, et l'aide de l'option vous le dit : elle peut couper la connexion Tailscale, donc la session SSH qui passe par cette connexion. Si la clé est déjà expirée, vous n'avez de toute façon plus de tailnet pour y arriver. Passez par l'adresse IP publique du serveur ou par la console de votre hébergeur.

Un nœud tagué expire-t-il un jour ?

Par défaut, non. Quand un tag est appliqué à un appareil pour la première fois et que celui-ci est authentifié, l'expiration de clé est désactivée. Un administrateur peut la réactiver depuis le menu de la machine, et le comportement redevient alors celui d'un appareil ordinaire. Le tag ne dispense pas des règles ACL : elles doivent viser tag:server pour que le nœud reste joignable.

La clé d'authentification expire dans 90 jours : mon serveur va-t-il tomber ?

Non. La durée de validité d'une clé d'authentification, de 1 à 90 jours, limite la période pendant laquelle elle peut servir à enrôler une machine. Elle n'a aucun effet sur un nœud déjà joint. Ce qui décide de la durée de vie du nœud, c'est l'expiration de sa clé de nœud, et elle est désactivée par défaut si la clé d'authentification portait un tag.

Comment savoir quand la clé de mon serveur expire ?

Dans la page Machines de la console, chaque ligne montre si l'expiration est désactivée ou la date à laquelle elle tombe. Depuis n'importe quel nœud, tailscale status --json expose KeyExpiry et Expired pour lui-même dans Self et pour chaque pair dans Peer, ce qui permet un contrôle automatique par cron.