Votre appareil se trouve derrière le NAT d’un opérateur, il peut ouvrir des connexions sortantes et il fait tourner un serveur SSH que personne ne peut atteindre. La demande qui arrive est généralement formulée comme « donnez-lui un VPN », ce qui est une réponse parmi plusieurs. Avant de l’accepter, décidez si vous avez besoin d’un seul port TCP d’administration ou d’un chemin routé vers un sous-réseau entier, car ce sont des projets différents avec une exposition différente.

Un tunnel inverse répond bien à la version étroite. L’appareil se connecte à votre concentrateur, lui demande d’écouter sur un port loopback et renvoie ce port vers son propre service SSH. Les administrateurs atteignent ensuite l’écouteur via le concentrateur, pas via l’internet public.

Trois conditions qui tranchent le choix

Notez-les avant toute configuration. Elles sont la frontière entre une entrée d’administration bornée et une extension de réseau, et les confondre est la façon dont un tunnel de cinq lignes devient un réseau plat sans propriétaire.

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

La troisième ligne est celle dont les gens discutent. Un tunnel vers le port SSH d’un appareil ne met pas ses voisins sur votre réseau, et il ne faut pas le faire passer pour tel au moyen d’une chaîne de redirections supplémentaires. Si le besoin est vraiment le LAN, dites-le et concevez-le à la place.

Côté concentrateur : un compte de relais borné

Donnez à chaque appareil son propre compte de relais avec authentification par clé publique et sans session interactive. Match bloc limité à ce compte garde l’autorisation réduite, et la clé privée reste sur l’appareil où elle a sa place.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 est la ligne intéressante. Elle refuse les sessions de shell et de sous-systèmes tout en autorisant la redirection dont l’appareil a besoin, si bien qu’une clé volée ne peut pas être transformée en connexion interactive. PermitListen fixe l’adresse et le port de l’écouteur côté concentrateur, et GatewayPorts no le maintient sur loopback au lieu de l’ouvrir au réseau où se trouve le concentrateur.

Testez la configuration effective avant de recharger, et gardez une seconde session ouverte pendant ce temps. Match bloc qui s’applique accidentellement à tout le monde, ou une faute de frappe dans le nom d’une option, est la façon classique de s’enfermer dehors de la machine que vous durcissez. Videz la configuration en cours et relisez les options plutôt que de faire confiance au fichier que vous venez d’écrire. Notez que la prise en charge des options diffère entre les versions, si bien qu’une ligne acceptée par un serveur plus récent peut simplement être ignorée par un plus ancien.

Côté appareil : une redirection qui échoue bruyamment

L’appareil ouvre la connexion et demande l’écouteur. Les deux adresses de l’argument -R ont des sens différents, et les lire de gauche à droite est le moyen le plus rapide de se rappeler laquelle est laquelle.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

La paire de gauche est l’endroit où le concentrateur doit écouter. La paire de droite est ce à quoi l’appareil se connecte quand une requête arrive, résolue depuis son propre côté. Les inverser produit un tunnel qui monte proprement et redirige au mauvais endroit, ce qui est pire qu’un échec.

ExitOnForwardFailure=yes fait sortir la commande lorsque l’écouteur demandé ne peut pas être établi, ainsi une boucle de redémarrage vous dit la vérité au lieu de laisser une session à moitié fonctionnelle. Elle ne dit rien de la santé ultérieure du service SSH local, alors associez-la à un gestionnaire de processus et à un vrai test de connexion occasionnel.

Ne remplacez jamais l’adresse d’écoute loopback par un joker pour éviter un saut supplémentaire. Ce seul changement est la différence entre un chemin d’administration et un port accessible publiquement, et il se produit généralement pendant le débogage puis reste. Si un collègue n’atteint pas le port via le concentrateur, corrigez la configuration du saut au lieu d’élargir la liaison. Loopback est tout l’argument de sécurité de cette conception.

Accès administrateur via le concentrateur

Un administrateur disposant d’un compte ordinaire sur le concentrateur peut sauter à travers lui jusqu’au port redirigé. Le compte de relais ne sert pas à cela, et c’est justement l’intérêt de les garder séparés.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

Vérifiez la clé d’hôte de l’appareil sous l’alias que vous avez choisi, car cette clé identifie l’appareil au bout de la chaîne et le tunnel n’est qu’un transport. La connexion de bout en bout authentifie toujours les deux extrémités ; un tunnel qui se termine sur un concentrateur partagé n’en fait pas pour autant un chemin de confiance.

Prenez la responsabilité du cycle de vie

Exécutez la commande de l’appareil sous un gestionnaire de processus avec exactement une instance active et une politique de redémarrage que vous avez choisie délibérément. Les options de keepalive détectent un pair mort ; elles ne ressuscitent pas un processus qui s’est arrêté.

Écrivez ensuite la procédure de mise hors service. Chaque appareil dispose de son propre écouteur et de sa propre clé, donc le démantèlement consiste à révoquer ce compte et à supprimer cette clé, non à faire tourner un secret commun à toute la flotte.

Enfin, rappelez-vous ce que le loopback vous apporte. Il limite l’exposition réseau et ne fait rien pour les autres utilisateurs locaux d’un concentrateur partagé, donc la politique d’accès du concentrateur lui-même doit encore être correcte. Référence sshd_config documente chacune des options utilisées ci-dessus, et il vaut la peine de lire intégralement les sections sur la redirection avant d’en élargir une seule.

Articles similaires