J'ai des problèmes avec SSH sur mon serveur Linux exécutant CentOS. Je peux très bien me connecter à mon serveur en utilisant PuTTY ou ssh à partir de Windows cmd. Il en va de même pour l'utilisation du FTP sécurisé. Je peux me connecter au serveur, obtenir une liste de fichiers et tout va bien. Le problème se produit lorsque j'essaie d'envoyer n'importe quelle quantité de données sur le réseau.
Chaque fois que j'essaie de transférer quoi que ce soit au-delà d'un certain seuil, la connexion échoue et je vois un message «Connexion réinitialisée par l'homologue». J'ai un fichier sql d'environ 3 Mo dans mon répertoire personnel. Si j'essaye de le FTP, il commencera le transfert et mourra après environ 48k a été transféré. Ensuite, il va initier une nouvelle connexion et transférer un autre 48k. Si j'utilise PuTTY et que j'ouvre une session, je peux me connecter et me connecter correctement. Si cat file.sqlj'essaye à nouveau, la connexion est interrompue et je reçois un message «Connexion réinitialisée par l'homologue». Passer de mon poste de travail local au serveur, c'est la même situation. J'ai pas mal de code source que je dois valider dans mon référentiel svn hébergé sur le serveur, mais le même message 'Connection reset by peer' apparaît.
Je sais que le problème est sur mon poste de travail local car je peux utiliser le macbook et ssh de ma femme sur le serveur sans aucun problème. Je peux ssh dans la boîte Linux d'un ami (en utilisant la même installation de mastic) et sftp sur mon serveur à partir de leur et télécharger le fichier, ouvrir une autre session ssh de sa boîte sur mon serveur et attraper le fichier. Donc, quelque chose se passe, mais je ne sais pas quoi. Quelqu'un a-t-il une idée?
Mise à jour
J'ai essayé de comprendre cela un peu plus, et il semble qu'il y ait une limite stricte de la quantité de données que je peux transférer en une seule session ssh. Je le frappe immédiatement si je le fais, cat file.sqlmais je peux également continuer à taper ls -lun nombre constant de fois et j'obtiendrai également le message «Connexion réinitialisée par l'homologue». J'ai essayé:
- générer de nouvelles clés ssh
- redémarrer mon routeur
- redémarrer mon ordinateur
- redémarrage du serveur distant
J'ai écrit un tcpdump sur le serveur distant, mais je ne comprends pas TCP à un niveau si détaillé que cela a beaucoup de sens pour moi. J'ai activé le débogage dans ssh et voici la partie du journal menant à la connexion en cours de réinitialisation:
Jul 24 23:10:56 server sshd[4507]: debug1: permanently_set_uid: 500/503
Jul 24 23:10:56 server sshd[4507]: debug1: Entering interactive session for SSH2.
Jul 24 23:10:56 server sshd[4507]: debug1: server_init_dispatch_20
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jul 24 23:10:56 server sshd[4507]: debug1: input_session_request
Jul 24 23:10:56 server sshd[4507]: debug1: channel 0: new [server-session]
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: session 0: link with channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: confirm session
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req pty-req
Jul 24 23:10:56 server sshd[4507]: debug1: Allocating pty.
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_pty_req: session 0 alloc /dev/pts/2
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req shell
Jul 24 23:10:56 server sshd[4508]: debug1: Setting controlling tty using TIOCSCTTY.
Jul 24 23:10:59 server sshd[4507]: Read error from remote host <my-ip>: Connection reset by peer
Jul 24 23:10:59 server sshd[4507]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: deleting credentials
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: closing session
Jul 24 23:10:59 server sshd[4505]: pam_unix(sshd:session): session closed for user <me>
Jul 24 23:10:59 server sshd[4505]: debug1: session_pty_cleanup: session 0 release /dev/pts/2
MISE À JOUR 2:
Il y a environ une semaine, j'ai modifié mes paramètres ssh sur mon serveur en utilisant ce post wiki: http://wiki.centos.org/HowTos/Network/SecuringSSH
Parce que j'ai parfois besoin d'accéder à mon serveur à partir du travail et parce que le port 21 est ouvert sur notre pare-feu, j'ai changé le port ssh en 21. Pour diagnostiquer davantage ce problème, j'ai essayé de rétablir mes paramètres ssh et j'ai changé le port ssh en 22 Faible et voici, le je ne rencontre pas l'erreur lorsque j'utilise le port 22. Changez-le à 21, et comme une horloge lorsque je frappe 48k de données transférées - Connexion réinitialisée par l'homologue.
Étant donné que je peux obtenir la connexion initiale et que je n'ai eu aucun problème dans le passé à établir des connexions ftp sur le port 21, il ne semble pas que ma configuration de pare-feu soit le problème.
Au moins à ce stade, le problème est limité au port ssh de mon serveur. Retournez-le à 21 et problèmes instantanés, remettez-le à 22, pas de problème du tout ...
Quelqu'un peut-il penser pourquoi le port d'écoute ferait une différence? Encore une fois, ce n'est que sur ma boîte Windows XP que cela cause des problèmes. Faites-moi savoir si quelqu'un a des idées sur ce qui pourrait provoquer cela.
Mise à jour 2:
Je viens de réduire le problème et je suis corrigé - c'est un problème de pare-feu, mais un problème de pare-feu Windows, pas sur mon routeur. Si j'utilise le port 21 et que je désactive le pare-feu Windows, je ne rencontre pas le message «Connection reset by peer». Pour répondre à la question évidente, oui, le port 21 est ouvert sur le pare-feu Windows.
Étant donné que cet ordinateur est derrière le pare-feu de mon routeur, je peux simplement le désactiver pour l'instant, mais je serais intéressé de comprendre ce qui se passe ici.