Tailscale et SSH : tailscale up, MagicDNS et ACL

Tailscale vous permet de vous connecter en SSH à un serveur qui n'a ni IP publique ni ports ouverts sur le routeur. Vous lancez tailscale up sur le serveur, vous vous connectez à l'app Tailscale sur votre téléphone avec le même compte, puis vous accédez à l'adresse 100.x de la machine ou à son nom MagicDNS. Les ACL décident qui peut entrer et sous quel utilisateur.

Comment installer Tailscale et lancer tailscale up sur un serveur Linux

tailscale up fait rejoindre la machine à votre tailnet et affiche une URL de connexion. Une fois authentifiée, la machine reçoit une adresse 100.x. Sous Linux, le script officiel installe à la fois le paquet et le service :

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4
tailscale status

tailscale ip -4 affiche l'adresse IPv4 de la machine dans le tailnet, et tailscale status liste les autres appareils avec leur nom et leur état. Le trafic entre les nœuds est chiffré via WireGuard. Chaque nœud ouvre sa connexion en sortie, vous n'avez donc pas besoin de rediriger le port TCP 22 sur le routeur ni d'avoir une IP publique.

Sur macOS, iOS et Android, vous ne tapez pas tailscale up. Vous installez l'app Tailscale et vous vous connectez depuis son interface.

Adresses 100.x de Tailscale et MagicDNS : quel hôte cible votre client SSH

Chaque nœud Tailscale reçoit une adresse de la plage 100.64.0.0/10, joignable uniquement à l'intérieur de votre tailnet. MagicDNS lui attribue aussi un nom qui correspond au nom de la machine. N'importe quel client SSH accepte les trois formes :

ssh [email protected]
ssh deploy@servidor
ssh [email protected]

Le nom court est le plus pratique. S'il ne se résout pas sur un appareil donné, utilisez plutôt le nom complet en .ts.net. Enregistrez la connexion sous son nom MagicDNS plutôt que sous l'IP. Ainsi, si le nœud se réenregistre et que son adresse change, le nom pointe toujours vers la bonne machine.

Si vous préférez ne pas dépendre de Tailscale, le réseau maillé privé Prialo résout le même problème : atteindre des machines sans ouvrir de ports.

Tailscale SSH vs OpenSSH avec clés : tableau comparatif

sudo tailscale set --ssh active Tailscale SSH sur le serveur. Tailscale répond alors aux connexions sur le port 22 qui arrivent par le tailnet et les authentifie avec l'identité de votre compte, si bien qu'aucune clé n'est nécessaire dans authorized_keys. L'alternative consiste à garder OpenSSH avec des clés et à utiliser Tailscale uniquement comme réseau.

Élément comparé	OpenSSH avec clés via Tailscale	Tailscale SSH
Authentification	Clé Ed25519 ou RSA dans authorized_keys	Identité du compte Tailscale
Qui accorde l'accès	sshd et authorized_keys sur chaque serveur	La section ssh du fichier de politique ACL
Réauthentification	Non disponible par défaut	L'action check exige de confirmer à nouveau la connexion
Si Tailscale est indisponible	La clé fonctionne toujours depuis le réseau local	Aucun accès par ce chemin
Client sur iOS/Android	N'importe quel client SSH avec la clé chargée	N'importe quel client SSH connecté au tailnet

Si vous restez sur les clés, utilisez Ed25519. OpenSSH le prend en charge depuis la version 6.5 (janvier 2014), et les clés ed25519-sk adossées à FIDO2 depuis la 8.2. Dans termi1, vous pouvez générer la clé directement sur le téléphone ; elle est conservée dans le stockage sécurisé du système, et la clé privée ne quitte jamais l'appareil.

ACL Tailscale pour SSH : limiter qui entre et sous quel utilisateur

Le fichier de politique Tailscale comporte deux niveaux. acls contrôle qui peut atteindre le port 22, et ssh contrôle qui peut utiliser Tailscale SSH et sous quel utilisateur local. Cet exemple n'autorise que le groupe des admins, et uniquement en tant que deploy, sur les serveurs étiquetés comme production :

{
  "groups": { "group:admins": ["[email protected]"] },
  "tagOwners": { "tag:prod": ["group:admins"] },
  "acls": [
    { "action": "accept", "src": ["group:admins"], "dst": ["tag:prod:22"] }
  ],
  "ssh": [
    { "action": "check", "src": ["group:admins"], "dst": ["tag:prod"], "users": ["deploy"] }
  ]
}

Vous appliquez l'étiquette au serveur avec l'option --advertise-tags=tag:prod de tailscale up. Avec "action": "accept", l'accès est immédiat ; avec "check", Tailscale vous demande de confirmer votre identité avant l'ouverture de la session. Chaque champ est expliqué dans la documentation officielle de Tailscale SSH.

Mosh, tmux et SFTP via Tailscale depuis votre téléphone avec termi1

Mosh démarre mosh-server via une connexion SSH initiale, puis bascule en UDP, sur les ports 60000-61000 par défaut. À l'intérieur du tailnet, ces ports n'ont pas non plus besoin d'être ouverts sur le routeur :

mosh deploy@servidor
tmux new -A -s main

termi1 maintient la session active avec Mosh quand vous passez du Wi-Fi aux données mobiles, et tmux conserve ce que vous avez laissé en cours d'exécution pour votre retour. Mosh ne fait ni redirection de ports ni redirection X11 : ouvrez donc une session SSH séparée si vous avez besoin d'un tunnel. Le clavier de termi1 dispose des touches Esc, Ctrl, Tab et des flèches pour piloter tmux. Son SFTP intégré vous permet d'envoyer ou de télécharger des fichiers via le même nom MagicDNS sans quitter la session.

Si vous marquez dans termi1 vos connexions aux serveurs tag:prod comme production, Production Guard empêche l'IA d'appuyer sur Entrée sur ces serveurs. Il retient aussi tout ce qui supprime, arrête ou modifie quelque chose avant que cela n'atteigne l'invite. L'app est disponible sur l'App Store pour iPhone et sur Google Play.

4 erreurs lors d'une connexion SSH via Tailscale

L'app Tailscale du téléphone est déconnectée. Si le VPN Tailscale n'est pas actif, ni les adresses 100.x ni les noms MagicDNS ne se résolvent, et le client SSH expire.
Relancer tailscale up avec des options différentes. tailscale up attend que vous répétiez toutes les options non définies par défaut que vous aviez configurées auparavant. Pour modifier un seul réglage, utilisez tailscale set.
Laisser le port 22 ouvert sur l'interface publique. Avec ufw, autorisez d'abord l'interface du tailnet, puis supprimez la règle générale : sudo ufw allow in on tailscale0 et sudo ufw delete allow 22/tcp. Vérifiez que vous pouvez entrer via Tailscale avant de la supprimer.
Mauvaises permissions avec OpenSSH. sshd rejette la clé si ~/.ssh n'est pas en 700 ou si authorized_keys n'est pas en 600.

Questions fréquentes

Tailscale a-t-il besoin de ports ouverts sur le routeur pour SSH ?

Tailscale n'a besoin d'aucun port ouvert sur le routeur pour SSH. Chaque nœud ouvre sa connexion en sortie, et le trafic est chiffré via WireGuard à l'intérieur du tailnet. Il suffit que le serveur et le téléphone soient connectés au même compte, avec des ACL qui autorisent le port 22.

Quelle est la différence entre Tailscale SSH et SSH avec clés ?

Tailscale SSH s'authentifie avec l'identité de votre compte Tailscale et applique la section ssh de vos ACL, si bien qu'aucune clé n'est nécessaire dans authorized_keys. SSH avec clés utilise OpenSSH classique via le tailnet et continue de fonctionner depuis le réseau local même quand Tailscale est indisponible.

Mosh fonctionne-t-il via Tailscale ?

Mosh fonctionne via Tailscale. Il démarre mosh-server par une connexion SSH initiale, puis utilise UDP à l'intérieur du tailnet, sur les ports 60000-61000 par défaut. Vous n'avez pas besoin d'ouvrir ces ports sur le routeur, mais le pare-feu local du serveur doit les autoriser sur l'interface Tailscale.

Puis-je utiliser MagicDNS au lieu de l'adresse 100.x ?

MagicDNS attribue à chaque machine du tailnet un nom qui correspond à son nom d'hôte, vous pouvez donc taper ssh deploy@servidor au lieu de l'adresse 100.x. Si le nom court ne se résout pas, utilisez le nom complet se terminant par .ts.net affiché dans la console d'administration de Tailscale.