Réseau Tailscale et OpenSSH
Tailscale fournit un chemin privé et des adresses 100.x. Il ne crée pas de service applicatif : le VPS doit toujours exécuter sshd sur le port 22.
client ssh WSL2 -> réseau Tailscale Windows -> IP Tailscale du VPS
-> sshd Ubuntu -> authorized_keys
Windows est ici le nœud du tailnet et WSL2 emprunte sa connectivité. Si WSL2 atteint déjà l’IP Tailscale du VPS, installer un second nœud dans WSL2 est inutile. Le comportement dépend toutefois du mode réseau WSL et du VPN : il faut tester.
Il s’agit d’OpenSSH sur Tailscale, pas de Tailscale SSH, qui prend en charge le port 22 du tailnet et l’autorisation. Ne lancez pas tailscale set --ssh pour cette architecture.
command -v tailscale || true
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status
tailscale ip -4
systemctl is-enabled tailscaled
systemctl is-active tailscaled
L’URL d’autorisation est une action humaine ; n’intégrez jamais de clé d’authentification au script. Un nœud « online » dans la console ne valide pas le trajet jusqu’au service.
ping -c 3 "$TAILSCALE_IPV4"
ssh -i "$HOME/.ssh/id_ed25519" \
-o IdentitiesOnly=yes \
-o PreferredAuthentications=publickey \
-o PasswordAuthentication=no \
"$VPS_USER@$TAILSCALE_IPV4"
Dans la session, printf '%s\n' "$SSH_CONNECTION" confirme les adresses source et destination. Si WSL2 expire, examinez le réseau/VPN/pare-feu Windows et conservez le SSH public jusqu’à la réussite d’une nouvelle session privée.