SSH par un second chemin privé pendant que le VPN reste actif

Une machine en atteint une autre via un VPN, et quelqu'un veut désormais le même shell par un réseau privé d'un fournisseur. La route existe, le ping réussit, et SSH refuse toujours. La cause habituelle est que le démon n'a jamais écouté sur la nouvelle adresse, donc il n'y a rien à quoi se connecter. C'est un problème de liaison d'adresse avant d'être un problème de pare-feu.

Pourquoi une nouvelle route ne crée pas un nouvel écouteur

Un socket en écoute est créé par un processus qui nomme les adresses qu'il acceptera. Une route indique seulement aux paquets où voyager ; elle ne crée pas d'écouteur à la destination. Lorsque sshd est configuré avec un seul ListenAddress, les connexions vers toute autre adresse locale sont refusées même si l'interface est active. Il en va de même pour une unité de socket qui possède le port, et c'est pourquoi la première vérification est toujours ce qui écoute réellement.

Comparez les deux chemins par l'adresse de destination plutôt que par le nom de l'interface. Un client se connecte à une adresse, et cette adresse doit être liée avant qu'une règle de pare-feu n'ait d'importance.

Listez les adresses et les écouteurs

Avant de modifier quoi que ce soit, notez les adresses de l'hôte et les sockets qui existent maintenant.

ip -br addr
ss -ltnp | grep ':22'

La liste des adresses montre quelle adresse privée est réelle et sur quelle interface, tandis que la liste des sockets montre si quelque chose y est lié. Un écouteur sur 0.0.0.0:22 accepte déjà toutes les adresses, donc une nouvelle liaison n'ajoute rien. Un écouteur sur une adresse précise explique immédiatement le refus. Si le port appartient à une unité de socket plutôt qu'au démon, la configuration du démon n'est pas toute l'histoire.

Ajoutez la liaison et gardez l'ancienne

OpenSSH accepte plusieurs entrées ListenAddress, donc le chemin VPN peut rester pendant que le privé est ajouté. Testez le fichier avant de le recharger.

sshd -t
systemctl reload sshd

Un test de configuration échoué laisse le démon en cours d'exécution intact, et c'est exactement ce que vous voulez lorsque vous êtes connecté par le chemin que vous modifiez. Gardez l'entrée existante, ajoutez la nouvelle adresse locale et confirmez que le service se recharge sans perdre la session en cours. Sur les installations activées par socket, ajoutez plutôt l'adresse à l'unité de socket et rechargez cette unité. Relisez ensuite la liste des écouteurs, car une liaison qui n'est jamais apparue signifie que le mauvais composant a été modifié.

Vérifiez la nouvelle session avant de fermer l'ancienne

Connectez-vous à la nouvelle adresse pendant que la session d'origine est encore ouverte, en utilisant une sortie détaillée pour voir quelle adresse et quelle clé ont été utilisées. Gardez la session d'origine ouverte jusqu'à ce que la sonde réussisse deux fois.

ssh -v [email protected]

Lisez les lignes de débogage concernant l'adresse de destination et la clé d'hôte présentée. Confirmez l'empreinte de la clé d'hôte avec une valeur à laquelle vous faites déjà confiance, au lieu d'accepter une clé inconnue parce que le réseau est décrit comme privé. La nouvelle destination a besoin de sa propre entrée known_hosts, et c'est attendu. Ce n'est qu'une fois le chemin privé fonctionnel que l'ancienne session de gestion doit être fermée.

SSH protège le transport, mais ne rend pas deux réseaux équivalents à lui seul. Décidez si la confiance du transit privé correspond aux données avant de vous y appuyer.