ssh_exchange_identification: Connection closed by remote host

[CoolRaoul]

il y a 7 minutes, Lokomass a dit :

J'ai des choses qui s'affichent mais je ne sais pas si je peux les poster ici :)

Pas la peine, le but était de voir si un flux passait ou pas

Tu peux lancer maintenant un demon sshd en premier plan sur un port dédié (faut qu'il soit ouvert dans le bon sens entre les deux sites) pour avoir des diags directement à l'écran.

Comme cela: 

/usr/syno/sbin/sshd -p 9999 -d

et coté client , tu te connectes en ajoutant  "-p 9999" à ta ligne de commande ssh. A noter que lancé comme cela le sshd ne vas traiter qu'une seule session et mourir ensuite.

(choisir ce qui t'arrange pour le numéro de port à la place de 9999)
 

 

Modifié le 7 janvier 2016 par CoolRaoul

[Lokomass]

OK mais du coup, le port que j’utilise en externe est 2222 redirigé de ma box sur le @IPNAS (port 22)

Du coup si j'écoute d'un côté sur le 22 avec ta commande il me dit port in use...

Et de l'autre côté je ne peux arriver que comme ça : ssh -p 2222 root@xxx.xxx.xxx.xxx

[loli71]

tu dois ajouter un deuxieme port externe sur ta box (2223 par exemple) redirigé vers le port temporaire du ssh pour faire les tests.

[Lokomass]

J'ai encore le même message sur le serveur source, rien ne se passe sur la cible..

[loli71]

normalement, la commande "sshd -p 9999 -d" devrait au minimum t'afficher des messages de debug au lancement du sshd non ?

 

tu dois même pouvoir mettre 3 "d" de suite pour plus de debug (-ddd)

Modifié le 7 janvier 2016 par loli71

[Lokomass]

Voilà

[loli71]

Le port 3306 est celui utilisé par mysql (et mariabd), donc si tu as une base de donnée activée sur ton syno, tu ne pourras pas utiliser ce port pour tes tests.

[Lokomass]

J'ai réussi, voici le résultat : côté source, même erreur que depuis le début, côté cible :

Server listening on :: port 9662.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 368
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3

 

[Lokomass]

C'est grave docteur ?

[Lokomass]

Je viens de comprendre pourquoi ça ne fonctionnait pas (merci pour aide en tout cas).

Figurez vous que l'IP publique depuis laquelle j'essaye d'accéder à mon syno est dans la liste des IP bloquées sur le syno "NAS" depuis le 06/01/2016.

Je ne comprends rien...... Le site B, depuis lequel je tente d'accéder est un site distant, qui a une IP dynamique (avec un dyndns).

Comment a-t-elle pu être bloquée ? Et surtout comment est-elle ajoutée dans la liste du blocage auto à chaque update de l'IP (parce que du coup ça fait un petit moment que ça change d'IP et que ça doit la bloquer en suivant ??)

Du coup je redémarre mon syno, (au démarrage, il établi une connection ssh pour récupérer des scripts), et hop IP bloquée de suite !!

Comment changer ça sachant que mon IP est dynamique et que je ne la connais pas ?

Modifié le 8 janvier 2016 par Lokomass

[Lokomass]

Bonjour à tous,

Je relance encore un peu le sujet, car j'ai trouvé pourquoi j'avais cette erreur mais j'aimerai ne plus l'avoir... 

Comme je disais, au démarrage le nas distant va exécuter un script qui va faire des appels ssh vers la cible (je n'avais jamais eu le problème jusqu'à présent). Ét c'est à ce moment là que l'IP est bloquée. 

Malheureusement l'IP est dynamique, du coup comment faire pour ne plus qu'elle l'a bloqué automatiquement ?? Est ce que c'est parce que mon script de démarrage n'est pas au bon endroit ? Ou se lance trop tôt/tard ? Est ce par rapport au nombre de ssh/scp dans le script ?

Merci

Modifié le 10 janvier 2016 par Lokomass

[gaetan.cambier]

si c'est un tcpdump, passe le en pv à coolraoul, c préférable, on peux parfois trouve pas mal de chose dans le dump ;)

[CoolRaoul]

il y a 42 minutes, Lokomass a dit :

Comme je disais, au démarrage le nas distant va exécuter un script qui va faire des appels ssh vers la cible (je n'avais jamais eu le problème jusqu'à présent). Ét c'est à ce moment là que l'IP est bloquée. 

Malheureusement l'IP est dynamique, du coup comment faire pour ne plus qu'elle l'a bloqué automatiquement ?? Est ce que c'est parce que mon script de démarrage n'est pas au bon endroit ? Ou se lance trop tôt/tard ? Est ce par rapport au nombre de ssh/scp dans le script ?

Si L'IP est bloquée c'est que le script a provoqué des erreurs d'authentification sur la cible. Suffit de corriger ces erreurs et plus de blocage.

Hypothèse (à vérifier): quand il est lancé au démarrage ton script ne "voit" pas la clé privé.

Modifie-le en ajoutant une log (en ajoutant pres du début "exec >/tmp/monscript.log 2>&1"), reboote le NAS et jette un oeil au contenu du fichier log.

Modifié le 10 janvier 2016 par CoolRaoul

[Lokomass]

Alors, j'ai testé et mon fichier /tmp/monscript.log est vide.

Mon script de base envoie des ssh et scp sur le serveur qui le bloque, ce script est nommé S99remets.sh et est situé dans /usr/local/etc/rc.d

Je ne comprends vraiment pas, je n'ai jamais eu ce souci auparavant..

[CoolRaoul]

il y a 53 minutes, Lokomass a dit :

Alors, j'ai testé et mon fichier /tmp/monscript.log est vide.

Mon script de base envoie des ssh et scp sur le serveur qui le bloque, ce script est nommé S99remets.sh et est situé dans /usr/local/etc/rc.d

Si le serveur bloquait effectivement ces commandes ssh-là, elles échoueraient et des erreurs émises par ces dernières s'afficheraient dans le .log. Le blocage doit être provoqué par autre chose.

Sur le serveur cible, dans panneau de configuration -> "sécurité" -> "blocage auto" -> "autoriser/bloquer la liste" -> "liste des blocages" tu peux voir l'heure ou le blocage est intervenu. Vérifie que si ca coincide ou pas avec l'heure de démarrage du NAS source.

Essaie aussi quand même d'ajouter la commande "set -x" juste apres la ligne "exec ..." dans S99remets.sh. Ca  ajoutera au log une trace d'éxécution  commande par commande qui pourrait t'aider à comprendre ce qui ce passe.

 

 

Modifié le 11 janvier 2016 par CoolRaoul

[Lokomass]

Ce n'est pas mon script qui est en cause après tous mes tests....

Sais-tu quels sont les répertoires qui exécutent des scripts au démarrage ? Je suppose qu'un truc pas net doit trainer quelque part...

[CoolRaoul]

Déjà, puisque ton script ne fait pas d'erreur (vu que son .log est vide) on peut déduire que le blocage est causé par quelque chose qui est déclenché *plus tard* dans la phase de démarrage. Donc à priori ne s'agit pas d'un script système.

Assure-toi également, d'apres le timestamp du blocage, que c'est bien lié au démarrage et pas quelque chose de récurrent (en cron ou gestionnaire de taches par exemple: n'aurais-tu pas mis en place des sauvegardes automatiques croisées de NAS à NAS en rsync dont l'authentification ne marcherait plus?)

A part ça, et surtout à distance, je n'ai pas d'autre idée.

 

[Lokomass]

Oui je suis sur que le blocage vient du boot du serveur, l'heure coïncide parfaitement.

J'ai carrément supprimer mon script au démarrage et j'ai quand même le blocage... On progresse du coup.

Mais je ne comprends pas, du coup d’où peut venir ces connexions ssh ? Aurais-tu la liste de tous les répertoires dans lesquels sont executés des scripts au boot ? Ou juste après ?

[CoolRaoul]

à l’instant, Lokomass a dit :

Aurais-tu la liste de tous les répertoires dans lesquels sont executés des scripts au boot ? Ou juste après ?

Probablement pas exhaustif:

• /usr/syno/etc/rc.d/*
• /usr/local/etc/rc.d/*
• /var/packages/*/scripts/start-stop-status  

[Lokomass]

Bon, j'ai vérifié tous ces répertoires mais rien... Quelque chose se passe, ce n'est pas dans les tables cron non plus j'ai vérifié.

Je ne vois pas comment trouver d'ou vient le problème...

[loli71]

Lance un tcpdump sur le syno qui fait le blocage auto avec comme filtre l'adresse ip du syno qui se retrouve bloqué, redémarre le syno qui se retrouve bloqué, tu verras peut être quel protocole exact provoque ce blocage, cela sera un début de piste :

Par exemple :

tcpdump -p -n -i eth0 -vv host <ip du syno qui se fait bloquer>

tcpdump -p -n -i eth0 -vv host <ip du syno qui se fait bloquer>

Attention à l'IP que tu mets, ca doit être l'IP vue par le syno qui fait le blocage (donc certainement l'IP internet de ta box)

 

EDIT: penses bien aussi a enlever le blocage qui est peut être déjà en cours avant de rebooter l'autre syno

Modifié le 12 janvier 2016 par loli71

[Lokomass]

J'ai bien eu un résultat avant le blocage, tu veux que je t'envoi ça par MP ? ou je peux interpréter tout seul ?

[loli71]

Il te suffit de regarder le début des lignes qui contiennent les adresses IP et regarder les ports sources et destinations pour voir si il en a de connu.

Tu peux mettre quelques lignes ici si tu veux de l'aide

[Lokomass]

Ok, donc je récapitule, voici ce que j'ai :

Mes deux NAS sont des synos. Lorsque je reboot le NAS-Maison, son IP est bloqué sur NAS.

Pourtant, j'ai bien vérifié qu'aucun de mes scripts n'est présent sur NAS-Maison, et j'ai vidé ses tables cron (dans le doute : echo > /etc/crontab).

Lorsque le NAS-Maison redémarre, si son IP sera bloqué (donc qu'elle ne l'ait pas déjà) le reboot est très très long, sinon, c'est beaucoup plus rapide.

Voici le résultat du tcpdump en PJ, et également le message sur NAS comme quoi l'IP est bloquée..

Petit bizarrerie, au moment ou je tape "reboot" dans la console de NAS-Maison, des choses arrivent dans le tcpdump de NAS.....

tcpdump.log

Modifié le 14 janvier 2016 par Lokomass

[Lokomass]

Ok, donc je récapitule, voici ce que j'ai :

Mes deux NAS sont des synos. Lorsque je reboot le NAS-Maison, son IP est bloqué sur NAS.

Pourtant, j'ai bien vérifié qu'aucun de mes scripts n'est présent sur NAS-Maison, et j'ai vidé ses tables cron (dans le doute : echo > /etc/crontab).

Lorsque le NAS-Maison redémarre, si son IP sera bloqué (donc qu'elle ne l'ait pas déjà) le reboot est très très long, sinon, c'est beaucoup plus rapide.

Voici le résultat du tcpdump en PJ, et également le message sur NAS comme quoi l'IP est bloquée..

Petit bizarrerie, au moment ou je tape "reboot" dans la console de NAS-Maison, des choses arrivent dans le tcpdump de NAS.....

 

 

SUITE :

J'ai supprimé TOUT script qui provenait de moi (.profile, scripts dans /usr/syno/scripts, ...) je n'ai plus aucune trace de mes scripts.

Maintenant, je me demande... Pour aller faire des connexion ssh vers mon serveur NAS sur SITE A, il doit forcément y avoir quelque part sur le serveur, quelque chose qui dit en dur : "ssh x.x.x.x" ??? C'est obligé ??? Du coup je vais essayer de faire une recherche partout du nom DNS du site A ? Je ne comprend vraiment plus rien...