J'ai en fait un problème un peu étrange. J'utilise Ubuntu Server 12.04, avec un ensemble minimal de packages: le système de base, sshd et un serveur IRC. Je dois autoriser quelqu'un d'autre à configurer le serveur pour qu'il se connecte à son réseau IRC. Cependant, ils semblent tomber après deux lignes de ls ou de chat.
Odder, cela ne se produit que sur ce serveur, et je n’ai pas pu le reproduire du tout avec PuTTY ou un client ssh. Où devrais-je chercher pour diagnostiquer cela? auth.log
indique une connexion et une authentification normales et ne donne aucun détail sur la suppression. fail2ban n'a pas de violation avec l'adresse IP d'origine.
Il s’agit d’une machine virtuelle avec un port redirigé (mode pont et connectivité réseau normale). Je peux me connecter localement, sur le réseau local et depuis un emplacement distant avec PuTTY sans aucun problème. L'autre personne peut se connecter à l'aide de ssh
sous Linux, mais rencontre la perte de connexion.
Les journaux côté serveur ne montrent rien d’extraordinaire.
Avant de commencer, assurez-vous que l'heure système aux deux extrémités est synchronisée. Cela aide avec la comparaison plus tard.
Exécutez tcpdump
aux deux extrémités, filtré pour TCP port 22. Vous indiquez que le client utilise PuTTY, donc je suppose que Windows. Vous pouvez obtenir Wirehark pour Windows et il dispose d'une fonctionnalité de capture que vous pouvez utiliser à la place de tcpdump
.
En utilisant tcpdump
, vous feriez ceci avec quelque chose comme: tcpdump -w/tmp/ssh.pcap -s0 -ieth0 port 22
. Avec Wireshark sous Windows, vous pouvez configurer une capture filtrée pour le port 22 à l'aide de l'interface graphique, puis enregistrer la capture sur le disque.
Ouvrez maintenant les deux captures avec Wireshark. Trouvez le point de déconnexion. Vous devriez pouvoir voir quelle extrémité a déclenché l’arrêt de la connexion (d’où une connexion FIN ou RST arrive-t-elle en premier?)
Vous pouvez également vérifier si un hôte tiers (un routeur ou un fournisseur de services Internet, par exemple) interfère avec la connexion. Vous allez identifier ceci si vous repérez un paquet qui arrive qui n'a jamais été envoyé de l'autre côté, par exemple. Si cela se produit, il s'agira probablement d'un paquet RST.
J'ai eu ce problème exact de connexion à un ancien serveur 12.04 à partir d'un LTS14.04 (précédemment mis à niveau à partir de 12.04)
J'ai trouvé que le problème est lié au MTU après l'exécution
Sudo ip li set mtu 1480 dev eth0
Le problème disparaît ..... et revient quand vous le remettez à 1500
(suppose que vous êtes sur une connexion câblée eth0)
J'ai connu des délais étranges avec ssh et j'ai résolu le problème en utilisant les éléments suivants:
Sudo sysctl -w net.ipv4.tcp_keepalive_time=50 \
net.ipv4.tcp_keepalive_intvl=10 \
net.ipv4.tcp_keepalive_probes=5
Je ne sais pas si cela aidera, mais peut-être que ça vaut la peine d'essayer.
Difficile à dire sans une meilleure description du problème (que signifie "laisser tomber"? TCP un démontage? TCP RST? Connexion bloquée?), Mais une interprétation possible de votre description est que il pourrait y avoir un problème avec la découverte du chemin MTU ...