Salut,

je fais un peu joujou avec le port forwarding de ssh. Et j'ai quelques soucis. En particulier, des fois la connexion tombe et quand je la reactive le port distant est toujours binder a un ssh qui n'est pas encore mort. Et donc le port forwarding ne marche pas. Est ce que vous connaissez une astuce pour que ssh attende que le port redevienne dispo pour reetablir le port forwarding ?

Tchus!

Erik

function connect(){
while true
do
ssh -options && break
done
}
De rien

Merci les mecs mais c'est une réponse qui est attendue ici, pas un sketch de collégiens.

godrik j'ai creusé un peu, apparemment depuis la version 5.1 le démon SSH n'utilise plus l'option de socket SO_REUSEADDR si l'option X11UseLocalhost a pour valeur no. Si tu as ce réglage, change-le à yes, ça devrait résoudre ton problème.

Le 07 décembre 2016 à 18:36:19 shmemory a écrit :
function connect(){
while true
do
ssh -options && break
done
}
De rien

mmm, c'est une reponse serieuse ou c'est une blague? Evidement que je met le ssh dans une boucle, c'est pas la question. ssh ne retourne pas meme si la redirection de port n'est pas possible parceque le port distant de la redirection est occupe. Du coup, il etablit une connexion sans faire de port forwarding au lieu de quitter avec un code d'erreur "back off".

google_bot, je vais regarder ca. On verra si ca change quelque chose.

Le 07 décembre 2016 à 17:39:14 godrik a écrit :
Salut,

je fais un peu joujou avec le port forwarding de ssh. Et j'ai quelques soucis. En particulier, des fois la connexion tombe

Cad ? c'est quoi ton erreur ? c'est du broken pipe ou ??

et quand je la réactive le port distant est toujours binder a un ssh qui n'est pas encore mort. Et donc le port forwarding ne marche pas. Est ce que vous connaissez une astuce pour que ssh attende que le port redevienne dispo pour rétablir le port forwarding ?

http://serverfault.com/questions/473474/how-to-make-sure-that-ssh-is-ready-to-go-while-booting

until nc -zvw 1 $host 22; do
  sleep 2
done
ssh $host $cmd

En vrai tu peux check avec nc ton port, et basta.

Cad ? c'est quoi ton erreur ? c'est du broken pipe ou ??

C'est du insérer-foirage-TCP-ici, je ne pense pas que godrik se plaigne de ça en particulier, c'est plutôt le délai nécessaire à la reconnexion avec port-forwarding le souci.

http://serverfault.com/questions/473474/how-to-make-sure-that-ssh-is-ready-to-go-while-booting

until nc -zvw 1 $host 22; do
  sleep 2
done
ssh $host $cmd

En vrai tu peux check avec nc ton port, et basta.

Pour l'amour du ciel vous savez lire ou bien?

la redirection de port n'est pas possible parceque le port distant de la redirection est occup

Le port 22 fonctionne très bien les enfants. Tout va bien, pas de panique.
Le problème se situe ailleurs, sur un autre port utilisé en port-forwarding. Epargnez-moi la nécessité de faire un schéma.

Le port 22 fonctionne très bien les enfants. Tout va bien, pas de panique.

Le problème se situe ailleurs, sur un autre port utilisé en port-forwarding. Epargnez-moi la nécessité de faire un schéma.

Ben dans cas tu fais le netcat sur l'autre port utilisé, non ?
Le script avec netcat me paraît pertinent

en fait le probleme est sur la machine distante, le port que je veux rediriger de la bas est bloquer. Je fais un genre de

ssh -N -R 1234:localhost:22 distant

Mais le port 1234 de la machine distante est occupe par le ssh d'avant qui n'est pas encore mort du cote distant. Du coup, je prend un "le port 1234 est deja utilise" et la redirection ne se fait pas, et SSH ne sort pas avec un message d'erreur. Si SSH me mettait un code d'erreur, je ferais du back off, et je remettrais la connexion x secondes plus tard.

Mais l'idee de tester avec netcat la connexion depuis ssh n'est pas bete. Un truc du genre
while (true);
do
ssh -R 1234:localhost:22 "test que la redirection fonctionne avec netcat toutes les 20 secondes, sinon quitte"
sleep 10
done

Je l'ecris dans le week end, et je reviens vers vous.

Le 08 décembre 2016 à 14:49:19 shmemory a écrit :

Le port 22 fonctionne très bien les enfants. Tout va bien, pas de panique.

Le problème se situe ailleurs, sur un autre port utilisé en port-forwarding. Epargnez-moi la nécessité de faire un schéma.

Ben dans cas tu fais le netcat sur l'autre port utilisé, non ?
Le script avec netcat me paraît pertinent

Cimer chef

Après j'ai peut-être mal compris la question ?

des fois la connexion tombe et quand je la réactive le port distant est toujours binder a un ssh qui n'est pas encore mort.

La connexion tombe, genre tu as une connexion qui drop ? t'habite en afrique comme moi où bien ?

Pour faire simple moi j'ai compris
- Sa connexion drop
- Le port du ssh fait d'la merde en barquette parce que la connexion a laché
- Il veut savoir quand le port sera re-dispo ?

Sinon j'ai mis le port 22 google_bot, c'est juste pour la déco

Après j'ai peut-être mal compris la question ?

des fois la connexion tombe et quand je la réactive le port distant est toujours binder a un ssh qui n'est pas encore mort.

La connexion tombe, genre tu as une connexion qui drop ? t'habite en afrique comme moi où bien ?

Bah eventuellement une connexion, ca drop. En l'occurence je connecte une machine derriere 3 firewall a une autre machine derriere deux firewall sur un autre continent. C'est pas completement inattendu d'avoir des deconnexion.

Pour faire simple moi j'ai compris
- Sa connexion drop
- Le port du ssh fait d'la merde en barquette parce que la connexion a laché

Le port de redirection 1234 sur la machine distante est encore occupe par le process zombie ssh de la connexion d'avant. C'est un probleme standard quand un process meurt (et en l'occurence je pense qu'il n'est pas encore mort), les sockets en listen mettent un peu de temps a etre recycler par le systeme d'exploitation.

- Il veut savoir quand le port sera re-dispo ?

ou plus precisement, je voudrais que ssh reactive la redirection de port une fois le port disponible a nouveau.