Verrouiller un Droplet avec Tailscale et SSH privé

Pour verrouiller un Droplet avec Tailscale, établissez d’abord une connexion authentifiée au serveur, puis retirez l’accès SSH public. Ce guide utilise un nouveau Droplet DigitalOcean sous Ubuntu 24.04 LTS, une clé SSH et un petit réseau Tailscale. Vous obtiendrez une session OpenSSH classique transportée par Tailscale, avec les connexions entrantes publiques bloquées.

L’ordre compte davantage que le nombre d’outils de sécurité. Gardez la session initiale ouverte jusqu’à ce qu’une deuxième connexion privée fonctionne. Un port fermé ne suffit pas si vous ne pouvez plus administrer la machine. Nous vérifierons les accès autorisés, les refus et le redémarrage avant de considérer la configuration comme prête.

Ce guide concerne un serveur privé. Un site public, un serveur de messagerie ou un jeu public demande d’autres règles entrantes. N’appliquez pas la configuration finale à une machine qui héberge ces services. Utilisez un nouveau Droplet pour comprendre chaque exception ajoutée.

J’utiliserais cette configuration pour un serveur d’automatisation personnel, un tableau de bord interne ou le guide Home Assistant qui suit. Tailscale évite de modifier la liste des adresses autorisées à chaque changement de réseau Wi-Fi. En contrepartie, il faut gérer un compte supplémentaire, un client sur chaque appareil et une politique d’accès.

Une restriction par adresse IP reste raisonnable pour un bureau dont l’adresse est fixe. SSH public avec des clés peut être exploité correctement, mais conserve un service joignable à maintenir. Tailscale réduit cette exposition. Il ne corrige pas les applications vulnérables et ne protège pas un ordinateur volé déjà autorisé. Activez le verrouillage des appareils et l’authentification multifacteur des comptes.

Il vous faut un compte DigitalOcean, un compte Tailscale et une clé SSH sur votre ordinateur. Installez le client Tailscale local et connectez-vous avant de modifier le serveur. Les commandes supposent un terminal de type Unix. Sous Windows, utilisez WSL avec une route Tailscale locale fonctionnelle. Conservez la clé privée sur votre ordinateur. Seule la clé publique va sur le Droplet.

Choisissez une offre adaptée à l’application prévue. SSH seul ne justifie pas beaucoup de mémoire. Vérifiez le prix affiché lors de la création, y compris le stockage et les sauvegardes. Un Droplet CPU arrêté reste facturé jusqu’à sa destruction. Tailscale propose une offre Personal pour les usages personnels admissibles. Vérifiez séparément ses limites actuelles et les conditions professionnelles.

Avant de fermer SSH, repérez la Recovery Console dans les paramètres du Droplet et vérifiez vos identifiants de connexion locale. La Droplet Console ordinaire utilise le réseau et ne remplace pas ce secours. Conservez le mot de passe d’un compte local dans votre gestionnaire de mots de passe. Désactiver les mots de passe SSH ne supprime pas ce mot de passe local.

Créez un Droplet Ubuntu 24.04 LTS en sélectionnant votre clé publique SSH. Attachez un Cloud Firewall dédié dont la seule règle entrante temporaire autorise TCP 22 depuis votre adresse IPv4 publique actuelle avec le masque /32. Pour une connexion IPv6, utilisez votre adresse exacte avec /128. Gardez les autorisations sortantes par défaut pour cet exercice. Vérifiez que le pare-feu est bien attaché à cette machine.

Connectez-vous comme root à l’adresse publique. Remplacez PUBLIC_IP dans la commande. Vérifiez l’empreinte de la clé hôte par une console de confiance avant de l’accepter. Dans la session root, installez les mises à jour et créez le compte avec adduser operator. Choisissez son mot de passe local, puis exécutez usermod -aG sudo operator. Copiez le fichier authorized_keys existant avec les commandes ci-dessous.

Ouvrez un autre terminal et connectez-vous comme operator à l’adresse publique. Exécutez sudo -v. Continuez uniquement si la connexion par clé et sudo fonctionnent. Gardez la session root ouverte comme secours temporaire. Ne modifiez pas encore les options d’authentification SSH.

Depuis la session operator, téléchargez le programme d’installation officiel dans un fichier, lisez-le et exécutez-le après vérification. Il configure la source de paquets adaptée. Exécutez ensuite sudo tailscale up et ouvrez son URL d’authentification sur votre ordinateur. Ne publiez pas cette URL d’inscription et ne placez aucune clé réutilisable dans le dépôt compagnon.

Exécutez tailscale ip -4 sur le Droplet et notez son adresse 100.x. Dans un nouveau terminal local, connectez-vous comme operator à cette adresse. Cette connexion utilise toujours votre clé et le serveur OpenSSH du système. Nous n’activons pas Tailscale SSH, qui possède une authentification et une politique distinctes. Exécutez hostname puis sudo -v pour vérifier la machine et les droits.

Si la connexion échoue, arrêtez-vous ici. Vérifiez que les deux appareils sont en ligne dans le même réseau Tailscale, que la politique autorise la connexion et que sshd fonctionne. Ne retirez pas SSH public pour essayer de résoudre ce problème. Une ancienne session ouverte ne prouve pas qu’une nouvelle connexion fonctionne.

Ouvrez l’éditeur de politique Tailscale et sauvegardez son contenu actuel. Pour un nouveau réseau d’apprentissage, partez du fichier ssh-only.json du compagnon. Remplacez operator@example.com par votre identifiant Tailscale exact et outsider@example.com par un second utilisateur inscrit qui ne doit pas avoir accès. Gardez l’ordinateur personnel associé à son utilisateur. Attribuez uniquement au serveur tag:private-server dans la page Machines après avoir enregistré la définition du propriétaire du tag.

La politique autorise le groupe operators à joindre TCP 22 sur ce tag. Elle comprend des tests pour SSH autorisé et les ports applicatifs refusés. Lancez la validation de l’éditeur avant d’enregistrer. L’exemple n’accorde aucun accès à TCP 443 ou 8123. L’absence de permission pour les autres utilisateurs est volontaire.

Dans un réseau existant, adaptez la politique sans remplacer les règles sans rapport avec ce serveur. Les autorisations des grants et des anciennes ACL s’additionnent. Une règle précise n’annule pas une ancienne autorisation générale. Retirez ou réduisez les règles plus larges qui atteignent aussi ce serveur, puis lancez les tests de refus. Reconnectez-vous après l’attribution du tag, car celle-ci change l’identité du nœud.

Dans la session privée fonctionnelle, installez UFW si nécessaire avec sudo apt-get install ufw. Refusez les connexions entrantes par défaut, gardez les sorties autorisées et ajoutez la règle tailscale0 ci-dessous avant d’activer UFW. Vérifiez que IPv6 est activé dans /etc/default/ufw pour couvrir aussi cette famille d’adresses. Lisez le message d’activation avant de répondre oui.

Examinez sudo ufw status numbered. Retirez chaque autorisation publique avec sudo ufw delete NUMBER en utilisant son numéro affiché. Relisez la liste après chaque suppression, car les numéros changent. Conservez la règle tailscale0. Le refus par défaut n’annule pas une ancienne autorisation. Ne réinitialisez pas aveuglément un pare-feu existant.

Retirez maintenant la règle entrante temporaire TCP 22 du Cloud Firewall DigitalOcean. La configuration finale ne contient aucune règle entrante et conserve les sorties TCP, UDP et ICMP pour IPv4 et IPv6. Examinez tous les pare-feu attachés directement ou par tag. Un autre pare-feu permissif peut rouvrir l’accès. N’utilisez pas l’adresse Tailscale 100.x comme source SSH cloud, car le pare-feu cloud voit le transport extérieur, pas la session privée déchiffrée.

Sans autorisation UDP entrante, Tailscale peut passer par un relais. Cela convient à l’administration si les tests fonctionnent. N’ouvrez pas TCP 22, 443 ou 8123 publiquement pour améliorer la connexion. Consultez les diagnostics avant d’envisager l’autorisation UDP facultative documentée, dont le rôle est différent.

Une fois la clé operator testée sur Tailscale, désactivez les mots de passe SSH, l’authentification keyboard-interactive et la connexion SSH root. Sur cet Ubuntu neuf, écrivez le fichier de configuration ci-dessous avec sudo. Conservez le mot de passe local operator testé dans la console. Ces paramètres concernent SSH. Vérifiez leur valeur effective, car les fichiers inclus et les blocs Match peuvent la modifier.

Exécutez sudo sshd -t avant de recharger SSH. Si la validation échoue, corrigez ou retirez uniquement le nouveau fichier depuis la session conservée. Après le rechargement, ouvrez une nouvelle connexion operator par Tailscale et exécutez sudo -v. Ne fermez pas la dernière session fonctionnelle avant ce test. Une vérification syntaxique locale ne prouve pas que l’authentification distante fonctionne.

Depuis l’ordinateur autorisé, ouvrez une nouvelle connexion SSH à l’adresse Tailscale en désactivant le multiplexage. Essayez ensuite l’IPv4 publique et l’IPv6 publique si elle existe. La connexion privée doit réussir. SSH public ne doit pas établir de session TCP. Une réponse publique permission denied signifie que le service SSH reste joignable et que le test réseau a échoué.

Essayez aussi SSH privé avec le second utilisateur inscrit. La connexion doit échouer avant l’authentification. Déconnectez ensuite Tailscale sur un appareil de test et vérifiez qu’il ne joint plus l’adresse privée. Reconnectez-le après le test. Notez l’appareil source, la destination, l’heure et le résultat de chaque essai. Ces observations valent davantage qu’une capture des interrupteurs du pare-feu.

Redémarrez enfin le Droplet depuis la session privée, attendez son retour et répétez les tests de nouvelles connexions. Examinez tailscale status, SSH et UFW après le redémarrage. Si les clés expirent, prévoyez la réauthentification avant leur expiration. Si vous désactivez l’expiration pour ce serveur, notez la raison et retirez le nœud dès sa mise hors service.

Si l’accès privé tombe, cherchez d’abord un nœud expiré ou une modification de politique dans la console Tailscale. Utilisez ensuite la Recovery Console et votre mot de passe local pour examiner tailscaled, SSH et UFW. Pour rétablir temporairement SSH public, autorisez uniquement votre adresse publique actuelle dans le Cloud Firewall et UFW. Réparez Tailscale, vérifiez une nouvelle connexion privée, puis retirez les deux exceptions.

La règle hôte tailscale0 fait volontairement confiance au trafic admis par Tailscale. Elle ne remplace pas les permissions par port du réseau Tailscale. Gardez des grants limités. Docker peut également modifier le filtrage indépendamment d’UFW. Tout futur port de conteneur publié demande une nouvelle vérification de l’exposition. Conservez le Cloud Firewall même si les règles locales semblent correctes.

Installez les mises à jour Ubuntu, OpenSSH et Tailscale, examinez les utilisateurs et retirez les anciennes clés SSH. Sauvegardez les données applicatives hors de la VM. Cette configuration limite la joignabilité réseau. Elle n’empêche pas un compte autorisé d’exercer ses permissions.

Pour le prochain guide, conservez la politique SSH seule jusqu’à la fin de l’accueil privé de Home Assistant. L’application recevra son grant TCP 443 après la restriction de son serveur HTTP. Si ce Droplet était un exercice, sauvegardez vos notes, détruisez la machine exacte dans DigitalOcean et retirez son nœud Tailscale. Un simple arrêt laisse la facturation active.

Pas dans ce guide. OpenSSH vérifie toujours votre clé et les permissions locales. Tailscale fournit la route privée et les règles d’accès réseau. Tailscale SSH est une autre fonction avec ses propres règles d’autorisation. Ces instructions ne l’activent pas.

Seulement si ses droits correspondent à votre objectif. Une règle générale peut laisser chaque membre joindre le serveur malgré un grant plus précis. Examinez la politique complète et testez les refus avec un autre utilisateur inscrit avant d’héberger des applications privées.

Essayez d’abord sans règle entrante. Tailscale peut utiliser un relais lorsque la connexion directe est impossible. Vérifiez de nouvelles sessions et les reconnexions depuis vos réseaux réels. Une règle UDP facultative pour le transport est distincte de l’ouverture publique de SSH ou d’une application.

Utilisez la Recovery Console DigitalOcean avec vos identifiants locaux. La Droplet Console ordinaire dépend du réseau. Réparez le nœud ou rétablissez temporairement SSH depuis votre seule adresse dans les deux pare-feu. Retirez ces exceptions dès que l’accès privé fonctionne.

Vous avez établi une entrée réseau restreinte. Il reste les mises à jour, les comptes, les permissions applicatives, les sauvegardes et la récupération. Répétez les tests publics et les refus après chaque nouveau service, changement de politique ou ajout de pare-feu.