Erreur réseau PuTTY: Abandon de la connexion provoqué par le logiciel
J'ai un problème étrange: lorsque j'utilise PuTTY avec SSH pour se connecter à un serveur Linux hébergé dans VMware sur mon ordinateur Windows 7, j'ai souvent l'erreur de dire "Network error: Software caused connection abort", puis PuTTY SSH. la fenêtre est inactive. D'habitude, je peux me connecter au serveur avec PuTTY et faire quelque chose, mais après un temps aléatoire (environ une ou deux minutes), j'obtiens cette erreur. Et parfois, je ne peux même pas me connecter, ce qui entraîne une erreur de timeout.
J'imagine que quelque chose ne va pas avec mon lecteur VMware, car j'ai un autre bureau Ubuntu hébergé dans VMware en tant que serveur de référentiel de code, et le plus souvent une erreur de délai d'attente lorsque je fais une mise à jour/validation SVN. Cependant, je suppose aussi que Windows 7 a quelque chose de bizarre, car le même serveur Ubuntu hébergé dans VMware en tant que référentiel de code fonctionne très bien sous Windows Vista! Il semble que toutes les mauvaises choses se produisent après le passage de Windows XP à Windows Vista, puis à Windows 7!
Quelle pourrait être la raison de ce problème et comment peut-il être résolu?
Supplément :
J'ai effectué une recherche sur Google et appliqué toutes les méthodes d'aide, notamment:
- Activer sshd
TCPKeepAlive - Définissez sshd
ClientAliveIntervalsur900etClientAliveCountMaxsur3 - Définissez le paramètre de connexion PuTTY 'secondes entre keepalives' sur
5.
Mais tout cela ne fonctionne pas! Et la session SSH dans PuTTY est toujours interrompue!
J'ai désactivé le pare-feu du serveur Linux et le pare-feu du client Windows 7, mais la connexion a toujours expiré! C'est vraiment énervant!
Il semble parfois que je puisse me connecter, mais que parfois, la connexion expire! Je ne sais vraiment pas pourquoi. Il me rend fou!
Une chose que je dois mentionner est que lorsque j'utilise PuTTY SSH pour me connecter à un serveur distant, tout va bien!
Quand j'ai échoué à me connecter, le ping a également échoué! Mais comment cela peut-il arriver? J'utilise VMware Player pour héberger le serveur Linux sur ma machine locale!
PuTTY a une fonctionnalité qui tente de résoudre ce problème:
Network Error: Software caused connection abort
- Démarrer PuTTY
- Chargez vos paramètres de connexion si vous les avez enregistrés
- Cliquez sur "Connexion"
- Sur la section "Envoi de paquets nuls pour garder la session active", modifiez-le en 5 secondes. 300 secondes peuvent être meilleures si les pannes de réseau sont votre problème, lisez les détails ci-dessous.
Comment maintenir pour empêcher la déconnexion avec PuTTY:
Certains routeurs de réseau et pare-feu doivent suivre toutes les connexions qui les traversent. Habituellement, ces pare-feu supposent qu'une connexion est inactive si aucune donnée n'est transférée dans un sens ou dans l'autre après un certain intervalle de temps. Cela peut entraîner la fermeture inattendue de sessions PuTTY par le pare-feu si aucun trafic n'est vu dans la session pendant un certain temps.
L’option keepalive (‘secondes entre keepalives’) vous permet de configurer PuTTY pour qu’il envoie des données à travers la session à intervalles réguliers, de manière à ne pas perturber la session de terminal réelle. Si vous constatez que votre pare-feu coupe les connexions inactives, vous pouvez essayer d'entrer une valeur non nulle dans ce champ. La valeur est mesurée en secondes. Ainsi, par exemple, si votre pare-feu coupe les connexions au bout de dix minutes, vous pouvez entrer 300 secondes (5 minutes) dans la zone.
Réduisez le problème en utilisant la connexion automatique de PuTTY et l'outil "Screen"
PuTTY ne peut pas gérer un réseau Wi-Fi de mauvaise qualité qui perd la connectivité plusieurs minutes à la fois. Une solution consiste à utiliser la connexion automatique et l'écran.
C’est un problème non négligeable pour PuTTY de resynchroniser votre terminal après une minute de perte de connexion Internet. Vous courez des risques d'attaques au milieu lors d'une panne. De toute façon, vous devrez vous ré-authentifier pour vous en assurer. PuTTY ne vous impose pas cela, il vous laisse simplement tomber.
Utilisez donc la connexion automatique pour que PuTTY puisse se connecter automatiquement en votre nom.
- Générez une clé privée avec l'outil puttygen sur l'ordinateur avec lequel vous utilisez PuTTY.
- Collez la clé publique dans votre
/home/youruser/.ssh/authorized_keyscôté serveur, sur le serveur sur lequel vous utilisez PuTTY allez vous connecter. - Rendre la clé privée accessible à PuTTY dans les paramètres de PuTTY Connexion-> SSH-> Auth
- Ajoutez la clé privée en spécifiant le fichier de clé privée sous: "Fichier de clé privée pour authentification".
- Enregistrez les paramètres de connexion PuTTY.
Ensuite, vous pourrez double-cliquer sur votre connexion via PuTTY, ce qui vous mènera directement au terminal sans saisir le nom d'utilisateur/mot de passe.
Alors maintenant, vous pouvez connecter un login à PuTTY sur cette connexion avec une combinaison de clavier comme F6. Alors, quand le wifi va mal et que vous êtes largué. Vous écrasez F6 et vous êtes de nouveau connecté.
MAIS vous perdez toujours l’état de votre terminal! Comment résoudre ce problème? Utilisez le programme "écran". Créez un nouvel écran en tapant 'screen'. Un nouvel écran est créé.
Lorsque vous êtes expulsé et que vous vous connectez automatiquement, vous pouvez vous reconnecter à votre écran. Voici un tutoriel sur la façon de faire cela: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/
Il est fastidieux de saisir screen et de vous reconnecter chaque fois que vous êtes abandonné. Vous pouvez donc écrire un script qui "vous ramènera automatiquement au dernier écran disponible" pour le rendre transparent.
Alors, quand le terminal PuTTY gèle. Cela ressemble à ceci: Vous faites un signe de mépris, écrasez Alt + F4 pour fermer PuTTY, écrasez F6. Et en 6 secondes, vous êtes de retour à l'endroit où vous vous êtes arrêté.
Encore meilleure solution, en théorie
En théorie, vous pouvez créer un script pour tout le processus ci-dessus, afin que le terminal détecte le moment où il a été abandonné et effectue toutes les étapes ci-dessus pour la restauration de la connexion Internet. Si quelqu'un connaît un programme qui fait cela, faites-le-moi savoir automatiquement. Ce serait chouette.
Sources:
http://the.earth.li/~sgtatham/PuTTY/0.58/htmldoc/Chapter4.html#config-keepalive
Résolution des problèmes liés à l’erreur réseau PuTTY
Software caused connection abort
Lisez ce que PuTTY a à dire à propos de l'erreur
Il s'agit d'une erreur générique générée par le code de réseau Windows lorsqu'il tue une connexion établie pour une raison quelconque. Par exemple, cela peut arriver si vous tirez le câble réseau à l'arrière d'un ordinateur connecté à Ethernet ou si Windows a une autre raison similaire de croire que tout le réseau est devenu inaccessible.
Windows génère également cette erreur s’il a abandonné la machine à l’autre extrémité de la connexion qui y répond. Si le réseau entre votre client et votre serveur tombe en panne et que votre client tente ensuite d'envoyer des données, Windows tentera à plusieurs reprises d'envoyer les données, puis abandonnera et supprimera la connexion. En particulier, cela peut se produire même si vous n’avez rien tapé, si vous utilisez SSH-2 et que PuTTY tente un échange de clé.
(Cela peut également se produire si vous utilisez Keepalives dans votre connexion. D'autres personnes ont signalé que Keepalives corrige cette erreur pour elles. (Il existe des avantages et des inconvénients de Keepalives.))
Nous ne connaissons aucune raison pour laquelle cette erreur pourrait survenir qui représenterait un bogue dans PuTTY. Le problème réside entre vous, votre système Windows, votre réseau et le système distant.
Essayez un autre client SSH
Très probablement, le problème existe quelque part entre PuTTY et le serveur SSH cible. Pour en fournir la preuve, utilisez un autre client SSH tel que ( http://kitty.9bis.net ) et voyez si le problème se pose également à ce sujet. Ce sera probablement ce qui isolera le problème de PuTTY.
Connexion Internet irrégulière suspecte
Le problème peut être la connexion Internet inégale. Connectivité Internet Contrôler le temps de disponibilité d'une connexion Internet est un bon moyen de déterminer si votre FAI perd des paquets et est à l'origine de la panne de PuTTY. Obtenez un logiciel qui teste le temps de disponibilité d'une connexion Internet. Par exemple, http://code.google.com/p/internetconnectivitymonitor/ . Des déconnexions fréquentes et longues d’Internet constituent une violation des exigences du service du FAI. Si tel est le cas, il sera difficile de prouver que c'est la faute du FAI, car le support technique blâme automatiquement ce genre de problèmes sur votre ordinateur, votre système d'exploitation, votre routeur et le câblage de votre domicile. Si vous utilisez Internet par câble et vivez dans les rues piétonnes, il est possible que du matériel défectueux chez votre voisin envoie de l'électricité statique sur la ligne pendant quelques secondes/minutes à la première mise sous tension. Enfin, il est possible qu'il y ait du matériel défectueux dans le réseau du FAI à votre domicile. Le coût du remplacement du matériel par les fournisseurs de services Internet est si élevé que souvent, ils ne le feront pas à moins que le nombre d'abonnés dans une zone donnée soit suffisant pour en garantir le coût.
Suspectez le routeur filaire/sans fil
Êtes-vous connecté via un routeur filaire/sans fil? Quel âge a-t-il? Votre routeur pourrait être le problème. L'ancienne technologie sans fil et filaire peut devenir ancienne, abandonner des connexions sporadiquement et les redémarrer, provoquant la mort de PuTTY. Supprimez ces composants de l'équation et voyez si cela résout le problème. Essayez une connexion câblée et/ou un autre routeur pour voir si cela résout le problème. J'ai eu un routeur sans fil Linksys souffrir de cette mort lente et abandonner les connexions et les redémarrer.
Suspectez le système d'exploitation fournissant la connexion SSH
L'ordinateur auquel vous vous connectez avec SSH a une stratégie pendant plusieurs secondes pour maintenir les connexions SSH en vie. Ce nombre est bas pour des raisons de sécurité et vous pouvez l'augmenter. L'emplacement de ce paramètre dépend du système d'exploitation utilisé qui fournit SSH.
Si vous utilisez PuTTY via une machine virtuelle
Si vous utilisez PuTTY via une machine virtuelle, il peut exister une stratégie sur la machine virtuelle qui rompt votre connexion SSH avec le serveur lorsqu'il pense être inactif. L'augmentation de ces valeurs dépend du logiciel de la machine virtuelle et du système d'exploitation utilisés.
Si la connexion Internet est mauvaise, solutions de contournement de la connexion du client SSH:
Si votre FAI fournit une connexion instable, vous pouvez rendre les déconnexions moins pénibles avec "ssh autologin". Ce que vous faites est de générer une clé publique et privée. Et vous dites à votre serveur étranger de laisser entrer automatiquement toute personne fournissant une clé privée précise. Votre problème n'est pas résolu complètement, mais lorsque la panne Internet se produit, il vous suffit de fermer la fenêtre, de cliquer deux fois sur une icône pour revenir immédiatement à la ligne de commande de votre dossier personnel sans entrer de nom d'utilisateur/mot de passe.
Cela vous aidera avec cela: Y at-il un moyen de "connexion automatique" dans PuTTY avec un mot de passe?
Dans une invite de commande avec privilèges élevés, exécutez ce qui suit:
C:\Windows\system32>netsh int tcp show global
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : automatic
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Si Receive Window Auto-Tuning Level est normal, vous aurez des problèmes. Désactivez-le et tout devrait fonctionner comme avant:
C:\Windows\system32>netsh int tcp set global autotuninglevel=disabled
J'ai travaillé avec CentOS serveurs de PC Windows et j'ai eu le même problème avec PuTTY. Une session n'a pas duré plus de 1 à 5 minutes. J'ai essayé de jouer avec les réglages de PuTTY (keepalives, etc.), mais ça n'a pas aidé du tout.
Enfin, j'ai trouvé la solution à mon cas. J'ai enregistré TCP sauvegarde à la fois sur le client et sur le serveur. J'ai découvert que 25 à 30 secondes avant la déconnexion, il y a plusieurs retransmissions de TCP segments dans le vidage du client (du côté du client et du côté serveur) et enfin, PuTTY envoie RST et ferme la session avec cette erreur. Dans le vidage du serveur, je n'ai vu aucun segment du client au cours de cette période, même RST. Cela signifie que de temps en temps, aucun segment TCP du client n'est transmis au serveur et cette période est d'environ 30 à 60 secondes. J'ai enregistré le cas plusieurs fois et il y a toujours eu des retransmissions et la TVD finale de PuTTY. Probablement quelque part sur la route, des paquets ont été abandonnés par des équipements de réseau.
Pour résoudre ce problème, j'ai augmenté le nombre maximal de retransmissions de données de la valeur par défaut 5 à 16. Cela pourrait empêcher la déconnexion de PuTTY trop rapidement. La variable est 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxDataRetransmissions'. J'ai ajouté cette variable manuellement, elle n'a pas été définie initialement dans le registre de Windows. Cela a aidé! Maintenant, je vois que PuTTY est suspendu de temps en temps, mais cela revient toujours au travail.
Pour résoudre le problème: 1. Enregistrez un cliché TCP et recherchez les retransmissions et le fichier RST avant de vous déconnecter. 2. Si vous trouvez les mêmes segments de retransmission/RST, ajustez le nombre de nouvelles tentatives côté serveur ou côté client (cela dépend du côté de RST).
Attention, la modification des paramètres TCP s'applique à tous les logiciels et au système d'exploitation lui-même.
L'erreur Erreur réseau: le logiciel a provoqué une interruption de connexion de PuTTY est le résultat s'il y aconflit d'adresse IP(deux ordinateurs ou plus ont la même adresse IP) sur le réseau. (J'ai eu ce problème avec un Raspberry Pi qui a obtenu la même adresse IP attribuée par le serveur DHCP qu'un périphérique/ordinateur non autorisé configuré manuellement pour utiliser la même adresse IP.)
Dans ce cas particulier, il pourrait s'agir d'un conflit d'adresses IP localement sur l'ordinateur Windows 7 ou avec un autre périphérique du réseau. Wireshark peut être utilisé pour localiser ce type d'erreur avec succès.
Onglet Connexion: garder en vie défini à "5" secondes et activé
Mais plus important:
Connexion ->SSH-> Kex , Nombre maximum de minutes avant la nouvelle clé : "2" (la valeur par défaut est 60).
Mon mastic perdait sa clé après un moment, provoquant le délai d'attente. Laisser tomber cette valeur à "2" minutes résolut le problème. Je reste connecté indéfiniment maintenant.
J'ai rencontré le même problème avec un WinSCP script ou une console graphique. Finalement, j'ai découvert que c'était lié à la vitesse (vitesse d'Internet - notre serveur est sur Internet). J'ai déplacé le script vers un emplacement différent sur le réseau, un site différent et l'interface graphique et le script ne se sont pas bien déroulés.
Il a été trié après de nombreuses analyses et tri.
L'erreur 10053 WSAECONNABORTED (interruption de connexion provoquée par le logiciel) est une erreur générique Winsock qui peut être émise pour diverses raisons.
La 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 de données (le destinataire ne reconnaît jamais les données envoyées sur un socket datastream).
Les raisons de ce problème peuvent aller des câbles réseau défectueux à la simple perte de connectivité. Il est impossible d'offrir une solution unique.
J'ai eu le même problème avec PuTTY après l'installation d'un nouveau modem routeur WLAN/3G pour se connecter à Internet. J'ai essayé toutes les solutions persistantes ci-dessus - et toutes celles du menu de configuration de mon routeur - sans aucun effet.
Ensuite, je me suis souvenu de quelque chose qui remonte aux années 90 lorsque j’avais un modem de ligne terrestre: le MTU (unité de transmission maximale), qui correspond à la taille maximale des blocs de données transférés - cela a eu un effet notable sur la stabilité de la connexion.
J'ai donc vérifié la configuration de mon routeur WLAN, trouvé le paramètre de MTU et l'ai changé d'une valeur fixe de 1424 à "Auto" (je voulais essayer une valeur plus petite, mais "Auto" sonne encore mieux). Après cela, je n'ai plus eu de problèmes avec PuTTY - la connexion est maintenant solide. J'espère que cela aide au moins quelqu'un avec le problème "Erreur réseau: le logiciel a provoqué une interruption de connexion".
En fait, je faisais souvent face à ces problèmes. J'ai cherché une solution en passant des heures mais aucune d'entre elles n'était efficace. Je partage la solution qui a fonctionné pour moi et j'espère que cela aidera également les autres.
J'ai Windows 10 en tant qu'hôte O/S et Redhat-7 en tant qu'invité O/S et ma connexion VMware avait un pont ponté. En tant que DBA, je dois rendre visite aux clients et définir ma configuration de réseau selon les locaux du client. Ainsi, chaque fois que je quitte les locaux du client et que je me connecte à un autre réseau via une connexion sans fil et que j’ouvre VM, je suis confronté au même problème que celui indiqué dans la question. J'ai donc réfléchi un moment et vérifié ma configuration pour les réseaux LAN Ethernet et Ethernet sans fil et j'ai trouvé une incompatibilité. Comme mon VM utiliserait automatiquement l'Ethernet physique entre deux pour le pontage. Ainsi, lorsque je réinitialise la configuration de réseau pour LAN/Ethernet sans fil sur DHCP, cela fonctionne à merveille et n'abandonne plus la connexion. [Vous pouvez également redémarrer votre ordinateur hôte après l'avoir défini sur DHCP.]
Vous devez activer TCPKeepAlive sous Linux.
C'est expliqué dans la FAQ de PuTTY sur le site Web lorsque vous recherchez cette erreur.
Si la machine virtuelle est en cours d'exécution sur votre matériel local, désactivez la conservation des paquets actifs.