Le déploiement NetBird présenté par Vultr illustre l'intérêt des réseaux privés pilotés par identité. Pour un serveur existant, le résultat à prouver reste concret : un administrateur autorisé entre, un compte révoqué échoue et Internet ne peut plus joindre directement SSH.
1. Choisir le chemin et préparer le secours
| Approche | Intérêt | Point à contrôler |
|---|---|---|
| VPN | Réseau privé pour plusieurs protocoles | Ne pas donner accès à tout le réseau |
| Bastion | Point d'entrée SSH central | Durcissement, disponibilité et comptes du bastion |
| Tunnel sortant | Pas de port entrant requis sur l'origine | Disponibilité du connecteur et du fournisseur |
| Accès Zero Trust | Décision par identité et politique | MFA, portée des droits et révocation effective |
Un VPN ou un bastion peut participer à une architecture Zero Trust ; son installation seule ne la constitue pas. Ici, le flux retenu est client SSH → Cloudflare Access et fournisseur d'identité → tunnel sortant → cloudflared local → sshd. L'identité Access et le compte Unix restent deux contrôles distincts.
Prérequis : domaine administré dans Cloudflare, droits de configuration Access/Tunnel, cloudflared installé sur client et serveur, clés SSH nominatives, sudo et console hors bande testée. Le serveur de l'exemple utilise UFW déjà actif. N'appliquez pas sa partie pare-feu à une autre pile sans adaptation.
sudo ss -lntpsudo sshd -tsudo ufw status verbosesudo ufw status numberedsudo systemctl status ssh --no-pagerRepérez toutes les ouvertures de 22, y compris profils OpenSSH, groupes cloud, NAT, IPv6 et règles générales. Notez l'adresse publique réelle et le chemin de secours. Gardez la session actuelle ouverte ; une session existante ne prouve pas qu'une nouvelle connexion fonctionnera.
2. Tester le tunnel avant de retirer l'entrée publique
- Créez d'abord une application Access pour le nom choisi, par exemple
ssh.example.com. Autorisez uniquement le groupe d'administration prévu. Configurez le SSO et imposez MFA dans la politique ou l'IdP selon les capacités de votre offre ; n'ajoutez pas de règle Bypass générale. - Créez le tunnel depuis le tableau de bord et installez son connecteur comme service sur le serveur. Le jeton d'installation est un secret : ne le mettez ni dans Git ni dans une capture d'écran.
- Ajoutez une route d'application publiée de type SSH vers
localhost:22. Cette destination suppose que cloudflared et sshd résident sur le même hôte. Maintenez les sorties réseau nécessaires au connecteur. - Vérifiez que la protection Access couvre exactement ce nom. Côté client, ajoutez à votre configuration SSH :
Host shop-admin HostName ssh.example.com User deploy IdentityFile ~/.ssh/id_ed25519 IdentitiesOnly yes ProxyCommand cloudflared access ssh --hostname %hVérifiez que cloudflared est dans le PATH du client. Remplacez le domaine et le compte, puis ouvrez une nouvelle session :
ssh shop-adminLe navigateur demande l'authentification auprès de l'IdP. Vérifiez ensuite la clé hôte SSH par un canal indépendant et l'accès sudo attendu. Testez un utilisateur non autorisé ; il doit échouer avant d'atteindre sshd.
Pour un serveur où les seuls accès 22 publics proviennent exactement de la règle UFW allow 22/tcp, après validation du tunnel et de la console :
sudo ufw delete allow 22/tcpsudo ufw status numberedCette commande retire cette règle précise, pas les autres autorisations. La politique entrante doit déjà refuser les connexions non autorisées. Retirez séparément les règles équivalentes identifiées et l'ouverture du pare-feu cloud, en IPv4 comme en IPv6. Ne réinitialisez pas le pare-feu et n'activez pas UFW à l'aveugle.
3. Vérifier fermeture, révocation et disponibilité
Depuis une machine externe autorisée à effectuer le test, remplacez l'adresse d'exemple :
nc -vz -w 5 203.0.113.10 22ssh shop-adminsudo journalctl -u cloudflared --since '-15 min'sudo journalctl -u ssh --since '-15 min'La connexion directe doit échouer, celle via Access réussir. Testez aussi l'adresse IPv6 réelle. Ces contrôles doivent utiliser de nouvelles connexions.
Corrélez identité Access, authentification Unix et événements sudo dans votre collecteur. Les journaux de connexion ne sont pas un enregistrement complet des commandes ; ajoutez une solution dédiée si cet audit est requis. Contrôlez également comptes retirés du groupe, échecs MFA, connecteurs indisponibles et latence de connexion.
Retirer un utilisateur d'un groupe ne garantit pas l'arrêt immédiat d'une session SSH déjà ouverte. Testez le délai de révocation, invalidez les sessions Access concernées et terminez les sessions Unix lorsque votre procédure l'exige.
Le tunnel ajoute des dépendances à l'IdP, au DNS et au fournisseur ; mesurez reconnexions et transfert sous charge. Pour la production, prévoyez la redondance des connecteurs selon la topologie et exercez une panne du fournisseur.
Le secours repose sur une console hors bande avec compte nominatif, MFA si disponible et credentials conservés hors du même IdP. Un opérateur autorisé peut y restaurer temporairement une règle 22 limitée à son IP d'administration, puis la retirer après réparation. Documentez motif, durée, responsable et logs. Ne restaurez pas une ouverture mondiale permanente comme rollback.
Sources : Vultr, réseau privé NetBird, Cloudflare, SSH avec cloudflared côté client.