Erreur réseau PuTTY : Le logiciel a provoqué l'abandon de la connexion

Onglet Connexion : keep alive réglé à "5" secondes et activé

Mais plus important encore :

Connexion -> SSH -> Kex , Nombre maximal de minutes avant une nouvelle clé : "2" (par défaut, 60).

Mon PuTTY perdait sa clé au bout d'un moment, ce qui provoquait le délai d'attente. En réduisant cette valeur à "2" minutes, j'ai résolu le problème. Je reste connecté indéfiniment maintenant.

J'ai eu le même problème avec PuTTY après avoir installé un nouveau routeur WLAN / modem 3G pour me connecter à Internet. J'ai essayé toutes les solutions keep-alive ci-dessus - et toutes celles dans le menu de configuration de mon routeur - sans résultat.

Je me suis alors souvenu de quelque chose qui remonte aux années 90, lorsque j'avais un modem téléphonique terrestre : le MTU (maximum transmission unit), c'est-à-dire la taille maximale des blocs de données transférés, qui avait un effet notable sur la stabilité de la connexion.

J'ai donc vérifié la configuration de mon routeur WLAN, trouvé le paramètre MTU et l'ai changé d'une valeur fixe de 1424 à "Auto" (je voulais essayer une valeur plus petite, mais "Auto" sonnait encore mieux). Après cela, je n'ai plus eu de problèmes avec PuTTY - la connexion est maintenant solide comme le roc. J'espère que cela aidera au moins quelqu'un avec le problème "Network error : software caused connection abort".

L'erreur 10053 WSAECONNABORTED (Le logiciel a provoqué l'abandon de la connexion.) est un générique Winsock qui peut être émise pour un certain nombre de raisons.

Le site explication officielle dit :

Cette erreur peut se produire lorsque le système de réseau local interrompt une connexion, par exemple lorsque Winsock ferme une connexion établie après l'échec de la retransmission des données (le récepteur n'accuse jamais réception des données envoyées sur une socket datastream).

Les raisons de ce problème peuvent aller de câbles réseau défectueux à une simple perte de connectivité. Il est impossible d'offrir une solution unique.

J'ai été confronté à ce problème à plusieurs reprises. J'ai cherché des solutions pendant des heures mais aucune d'entre elles n'a été efficace. Je partage la solution qui a fonctionné pour moi et j'espère qu'elle sera également utile à d'autres.

J'ai Windows 10 en tant que système d'exploitation hôte et Redhat-7 en tant que système d'exploitation invité et mon VMware avait une connexion pontée. En tant que DBA, je dois rendre visite à des clients et je dois définir ma configuration réseau en fonction des locaux du client. Ainsi, chaque fois que je quitte les locaux du client et que je me connecte à un autre réseau via le sans fil et que j'ouvre la VM, je suis confronté au même problème que celui mentionné dans la question. J'ai donc réfléchi un moment et vérifié ma configuration pour le LAN Ethernet et le Wireless Ethernet et j'ai trouvé un décalage. Comme ma machine virtuelle utilise automatiquement l'Ethernet physique parmi les deux pour le pontage. Donc, lorsque j'ai réinitialisé la configuration réseau pour LAN/Wireless Ethernet à DHCP, cela a fonctionné comme sur des roulettes et plus d'interruption de connexion. [Vous pouvez également redémarrer votre machine hôte après l'avoir configurée en DHCP].

J'ai rencontré le même problème soit avec un WinSCP script ou console GUI. Finalement, j'ai trouvé que c'est lié à la vitesse (vitesse Internet - notre serveur est sur Internet). J'ai déplacé le script à l'emplacement différent dans le réseau, site différent, et pas à la fois GUI et script allait bien.

Le problème a été résolu après beaucoup d'analyse et de tri.