Pourquoi un écouteur de proxy SSH inversé n’est joignable que sur le serveur
Vérifiez l’adresse de liaison de l’écouteur distant et le mode GatewayPorts avant de modifier le protocole du proxy ou les identifiants.
Un transfert distant peut fonctionner depuis le serveur SSH tout en refusant les connexions d’une autre machine, car il n’écoute que sur la boucle locale. Vérifiez d’abord l’adresse d’écoute réelle.
Côté serveur GatewayPorts | Liaison du transfert distant |
|---|---|
no, la valeur par défaut | Limite les écouteurs à la boucle locale |
yes | Force une liaison générique (wildcard) |
clientspecified | Autorise le client à demander une adresse de liaison précise |
Pour un écouteur destiné à une interface contrôlée, le serveur peut utiliser :
GatewayPorts clientspecifiedLe client demande ensuite une adresse appropriée dans sa spécification -R. Cette adresse doit exister sur la machine distante, et les autres restrictions de transfert s’appliquent toujours. L’option -g côté client n’est pas un contrôle interchangeable pour ce sens.
Trois autorisations restent distinctes : l’autorisation SSH de créer le transfert, l’accès réseau à son écouteur et la politique d’accès propre au service HTTP ou SOCKS. Une connexion SSH authentifie le créateur du tunnel ; elle n’authentifie pas chaque appelant ultérieur d’un écouteur partagé et n’ajoute pas de demande de mot de passe SOCKS.
Si un appelant distant ne peut toujours pas se connecter, inspectez l’adresse de liaison, les restrictions de transfert du serveur et le chemin du pare-feu dans cet ordre. Une fois que TCP atteint l’écouteur, une poignée de main de proxy échouée est un problème ultérieur.