termalUn NAS ou un petit serveur maison est la meilleure raison qu’ont la plupart des gens d’apprendre le SSH : c’est votre stockage, vos sauvegardes, vos médias, peut-être une poignée de conteneurs — et vous voulez l’atteindre depuis le canapé, depuis le travail, depuis votre téléphone. Le SSH, c’est la façon de faire sans écran branché sur la machine — depuis un portable, ou depuis un client SSH pour iPhone ou iPad quand vous êtes loin de votre bureau. Le piège, c’est le saut de « ça marche sur mon propre réseau » à « joignable de partout », là où le mauvais raccourci met votre home lab sur l’internet ouvert. Voici le chemin sûr, du début à la fin.
Première étape : l’atteindre sur votre propre réseau
Avant toute astuce, confirmez que le SSH fonctionne pendant que vous êtes chez vous, sur le même Wi-Fi ou le même LAN.
Activez le SSH. La plupart des NAS arrivent avec le SSH désactivé. Sur un Synology, Terminal & SNMP → Enable SSH service ; sur un QNAP, Control Panel → Telnet/SSH ; sur TrueNAS, Services → SSH. Un simple serveur Linux maison fait déjà tourner sshd en général. Quel que soit l’appareil, il y a un interrupteur — basculez-le, et notez le port (22 par défaut, parfois déplacé).
Trouvez son adresse. La liste des clients de votre routeur l’affiche, ou la page d’administration du NAS montre son IP LAN (quelque chose comme 192.168.1.50). Puis :
ssh admin@192.168.1.50Le nom d’utilisateur est le compte avec lequel vous vous connectez au NAS — admin sur de nombreux appareils, votre propre utilisateur sur une machine Linux, parfois root. S’il se connecte et vous dépose sur un shell, le plus dur est fait ; tout ce qui suit n’est que comment atteindre ce même shell depuis l’extérieur de la maison.
Deuxième étape : l’atteindre depuis l’extérieur — sans exposer le port 22
Le geste évident est de rediriger le port 22 de votre routeur vers le NAS. Ne le faites pas. Un port SSH joignable publiquement est repéré par les scanners en quelques minutes — vos journaux se rempliront de Connection reset by peer et de milliers de tentatives de connexion dès sa mise en ligne. Quatre meilleures façons qui n’ouvrent jamais votre routeur, à peu près par ordre de recommandation (le guide SSH derrière un NAT (en anglais) entre dans le détail de chacune) :
Un réseau overlay (le choix simple et sûr par défaut). Des outils comme Tailscale ou une configuration WireGuard placent vos appareils sur un réseau privé que eux seuls peuvent voir. Votre portable et votre NAS obtiennent des adresses privées stables, et vous faites ssh admin@100.x.y.z de partout comme si vous étiez chez vous — la machine n’est jamais exposée à l’internet public. Pour la plupart des home labs, c’est toute la réponse.
Un connecteur managé en connexion sortante uniquement. Si vous préférez ne pas monter vous-même un mesh ou un VPS, le Connector de Termalin est un petit agent que vous installez sur le NAS en une ligne. Il appelle vers l’extérieur Termalin — aucun port entrant sur votre routeur — et vous atteignez le shell de la machine depuis l’app ou le navigateur, en vous authentifiant avec un certificat à courte durée au lieu d’une clé qui vit sur le NAS. Le même principe d’aucun port entrant que le réseau overlay, sans faire tourner le relais vous-même.
Un tunnel inverse vers un VPS bon marché. Si vous louez déjà un petit serveur, le NAS peut appeler vers l’extérieur celui-ci et renvoyer son port SSH — vous atteignez alors le NAS en vous connectant au VPS. Rien d’entrant n’est jamais ouvert sur votre routeur domestique. C’est le schéma du tunnel inverse (en anglais), le cousin fait main du connecteur ci-dessus, et le bon outil quand un réseau overlay n’est pas envisageable.
DNS dynamique + redirection de port (la vieille méthode — seulement si vous y êtes obligé). Si vous tenez à exposer le SSH, au moins : sortez-le du port 22, n’autorisez que les clés (PasswordAuthentication no), et faites tourner fail2ban. Un nom d’hôte en DNS dynamique gère votre IP domestique changeante. Ça marche, mais vous entretenez désormais une surface d’attaque exposée sur internet pour une machine pleine de vos données personnelles — le réseau overlay existe précisément pour vous l’éviter.
Troisième étape : des clés, pas des mots de passe
Quelle que soit la voie choisie, connectez-vous avec une clé, pas un mot de passe. Générez-en une moderne — voyez Ed25519 vs RSA (en anglais) pour la version en trente secondes — mettez sa moitié publique dans le authorized_keys de l’utilisateur du NAS, et une fois que ça marche, désactivez la connexion par mot de passe. Une clé que vous pouvez révoquer par appareil vaut mieux qu’un mot de passe partagé par tous les comptes, et c’est ce qui fait réellement tenir la posture « n’exposez rien, clés uniquement » ci-dessus.
Laisser un agent IA aider à gérer la machine
Voici vers où vont les home labs en 2026 : au lieu de vous connecter vous-même en SSH pour voir pourquoi un conteneur est mort ou pourquoi un disque s’est rempli, vous demandez à un assistant — Claude Code, Cursor, un modèle local — d’aller regarder. C’est réellement utile. C’est aussi exactement là où les gens font l’erreur qu’ils ne feraient jamais avec un inconnu : confier à l’agent un shell sur la machine qui contient leurs sauvegardes.
L’instinct d’hésiter est le bon. Un agent qui a la clé de votre NAS peut tout faire ce que vous pouvez faire, et il peut se faire embarquer par une ligne de journal empoisonnée ou un nom de fichier malveillant qu’il lit au passage — le rayon d’impact (en anglais), c’est toute la machine, pas la seule tâche que vous avez demandée. La solution n’est pas d’abandonner l’idée ; c’est de changer ce que l’agent reçoit. Au lieu de la clé et d’un shell brut, l’agent devrait passer par quelque chose qui :
- détient la clé à sa place — l’agent se connecte, mais ne voit ni ne stocke jamais l’identifiant, de sorte qu’un contexte d’agent qui fuite n’est pas une connexion NAS qui fuite ;
- limite ce qu’il peut exécuter — une politique par hôte qui dit que cet agent peut exécuter ces commandes sur le NAS et rien d’autre (lire les journaux et l’usage disque, oui ;
rm -rf, non) ; - reste visible — vous suivez la session en direct et elle est consignée dans un journal d’audit, de sorte que « l’agent a libéré de la place » est quelque chose que vous pouvez réellement vérifier, pas croire sur parole.
C’est le même principe que le tunnel inverse et la connexion par clé uniquement ci-dessus — n’exposez pas plus que ce que la tâche exige (en anglais) — appliqué à l’agent plutôt qu’à internet.
Où Termalin s’inscrit
Termalin est un client SSH multiplateforme — Windows, macOS et Linux sur le bureau, plus une vraie app iPhone et iPad et un client dans le navigateur — conçu exactement pour ce type de problème. Il gère les tunnels (en anglais) qui atteignent une machine maison sans ouvrir votre routeur, garde ensemble l’utilisateur, la clé et le port de chaque hôte pour qu’un NAS soit un clic et non une IP à se rappeler, et affiche le disque, la mémoire et la charge de la machine en direct dans la barre de statistiques — si bien que « la machine est-elle seulement allumée, et le disque est-il plein ? » trouve réponse avant que vous ne tapiez une commande.
Et quand vous voulez qu’un agent aide, il se connecte via le serveur MCP intégré de Termalin : l’agent travaille sur votre accès SSH sans jamais détenir votre clé, borné par une politique de commandes par hôte (en anglais) que vous définissez, reproduite dans une grille de surveillance en direct, et consignée. Le home lab gagne un assistant compétent ; l’assistant n’obtient jamais les clés qui y mènent. Le forfait Free n’a aucune limite d’hôtes — récupérez-le et pointez-le vers votre NAS.
Termalin est un client SSH gratuit et multiplateforme avec un serveur MCP intégré — un accès SSH sûr pour vous comme pour les agents IA que vous laissez aider. Téléchargez-le, ou lisez le modèle de sécurité.