Suivi : Il semble que la série rapide de déconnexions coïncidant avec quelques mois de fonctionnement de chaque serveur soit probablement une coïncidence et ait juste servi à révéler le problème réel. La raison de l'échec de la reconnexion est presque certainement due aux valeurs de AliveInterval (réponse de kasperd). L'utilisation de l'option ExitOnForwardFailure devrait permettre au délai d'attente de se produire correctement avant la reconnexion, ce qui devrait résoudre le problème dans la plupart des cas. La suggestion de MadHatter (le kill script) est probablement le meilleur moyen de s'assurer que le tunnel peut se reconnecter même si tout le reste échoue.
J'ai un serveur (A) derrière un pare-feu qui initie un tunnel inverse sur plusieurs ports vers un petit VPS DigitalOcean (B) afin que je puisse me connecter à A via l'adresse IP de B. Le tunnel fonctionne de manière constante depuis environ 3 mois, mais a soudainement échoué quatre fois au cours des dernières 24 heures. La même chose s'est produite il y a quelque temps chez un autre fournisseur de VPS - des mois de fonctionnement parfait, puis soudainement de multiples défaillances rapides.
J'ai un script sur la machine A qui exécute automatiquement la commande tunnel ( ssh -R *:X:localhost:X address_of_B pour chaque port X) mais quand il s'exécute, il dit Warning: remote port forwarding failed for listen port X .
Entrer dans le sshd /var/log/secure sur le serveur montre ces erreurs :
bind: Address already in use
error: bind: Address already in use
error: channel_setup_fwd_listener: cannot listen to port: XLa résolution de ce problème nécessite le redémarrage du VPS. En attendant, toutes les tentatives de reconnexion donnent le message "remote port forwarding failed" et ne fonctionnent pas. Le tunnel ne dure plus qu'environ 4 heures avant de s'arrêter.
Rien n'a changé sur le VPS, et il s'agit d'une machine à usage unique, à utilisateur unique, qui sert uniquement de point de terminaison du tunnel inverse. Il exécute OpenSSH_5.3p1 sur CentOS 6.5. Il semble que sshd ne ferme pas les ports de son côté lorsque la connexion est perdue. Je suis incapable d'expliquer pourquoi, ou pourquoi cela se produit soudainement après des mois de fonctionnement presque parfait.
Pour clarifier, je dois d'abord comprendre pourquoi sshd refuse d'écouter sur les ports après l'échec du tunnel, ce qui semble être causé par sshd qui laisse les ports ouverts et ne les ferme jamais. Cela semble être le problème principal. Je ne suis simplement pas sûr de ce qui pourrait le faire se comporter de cette manière après des mois de comportement comme je l'attends (c'est-à-dire fermer les ports immédiatement et permettre au script de se reconnecter).
