Question Erreur réseau PuTTY: le logiciel a provoqué une interruption de la connexion


J'ai un problème étrange: quand j'utilise PuTTY avec SSH se connectant à un serveur Linux hébergé dans VMware sur mon local Windows 7, Je reçois souvent l'erreur en disant "Network error: Software caused connection abort" puis la fenêtre PuTTY SSH est inactive. Habituellement, je peux me connecter au serveur avec PuTTY et faire quelque chose, mais après une heure aléatoire (environ une ou deux minutes), je reçois cette erreur. Et parfois, je ne peux même pas me connecter, en obtenant une erreur en disant timeout.

Je suppose que quelque chose ne va pas avec mon VMware Player, car j’ai un autre bureau Ubuntu hébergé dans VMware en tant que serveur de référentiel de code, et il a plus souvent qu’une erreur de temporisation lorsque je fais une mise à jour / validation SVN. Cependant, je suppose également 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 arrivent après que je suis passé 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 pour vous aider, notamment:

  1. Activer sshd TCPKeepAlive
  2. Définir sshd ClientAliveInterval à 900 et ClientAliveCountMax à 3
  3. Définissez le paramètre de connexion PuTTY «secondes entre keepalives» à 5.

Mais tout cela ne marche pas! Et la session SSH dans PuTTY se casse toujours après un certain temps!

J'ai désactivé le pare-feu du serveur Linux et le pare-feu du client Windows 7, mais la connexion est toujours interrompue! C'est vraiment agaçant!

Il semble parfois que je puisse me connecter, mais parfois, le délai de connexion expire! Je ne sais vraiment pas pourquoi. Il me rend fou!

Une chose que je dois mentionner, c'est que lorsque j'utilise PuTTY SSH pour me connecter à un serveur distant, tout va bien!

Lorsque je n'ai pas réussi à me connecter, ping a également échoué! Mais comment cela peut-il arriver? J'utilise le lecteur VMware pour héberger le serveur Linux sur mon ordinateur local!


67
2018-06-09 02:12


origine


Avez-vous cette erreur lorsque vous utilisez activement la connexion ssh? ou après l'avoir laissé inactif pendant un moment? - MaQleod
Il est inactif pendant un moment. Mais parfois, je ne peux même pas vous connecter pour le délai d'attente. - Robert
Je vérifierais les paramètres d'expiration de session pour le serveur SSH. - MaQleod
Mais le plus souvent, je ne peux même pas vous connecter au serveur à partir de mastic pour un délai d'attente! - Robert
Ce problème a-t-il été résolu? J'ai essayé la plupart des solutions listées ci-dessous et rien ne semble fonctionner pour moi. D'autres suggestions? Je suis confronté exactement au même problème que le numéro original de Robert - user682765


Réponses:


Putty a une fonctionnalité qui tente de résoudre ce problème:

Network Error: Software caused connection abort
  1. Commencer mastic
  2. Chargez vos paramètres de connexion si vous les avez enregistrés
  3. Cliquez sur "Connexion"
  4. Dans la section qui dit "Envoi de paquets nuls pour conserver la session active", il a été modifié à 5 secondes. 300 secondes peuvent être mieux si les pannes de réseau sont votre problème, lisez ci-dessous pour plus de détails.

enter image description here

Comment garder des solutions pour empêcher la déconnexion avec Putty:

Certains routeurs réseau et pare-feu doivent suivre toutes les connexions via ces derniers. Généralement, ces pare-feu supposent qu'une connexion est morte si aucune donnée n'est transférée dans les deux sens après un certain intervalle de temps. Cela peut entraîner la fermeture inattendue des sessions PuTTY par le pare-feu si aucun trafic n'est détecté dans la session pendant un certain temps.

L'option keepalive ('Seconds between keepalives') vous permet de configurer PuTTY pour envoyer des données à travers la session à intervalles réguliers, sans perturber la session de terminal. Si votre pare-feu coupe les connexions inactives, vous pouvez essayer d'entrer une valeur différente de zéro 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 souhaiterez peut-être entrer 300 secondes (5 minutes) dans la boîte.

Réduisez le problème en utilisant l'authentification automatique et l'outil "screen"

Putty ne peut pas gérer un wifi de merde qui perd la connectivité pendant des minutes à la fois. Un travail autour de l'utilisation d'autologin et écran.

C'est un problème non trivial que le mastic ré-synchronise votre terminal après une minute de perte de connexion Internet. Vous courez des risques d’attaques au milieu lors d’une panne. Vous devrez vous authentifier de toute façon pour vous en assurer. Putty ne vous l'impose pas, il vous laisse tomber.

Donc, utilisez autologin afin que le mastic puisse se connecter automatiquement en votre nom.

  1. Générer une clé privée avec l'outil puttygen sur l'ordinateur avec lequel vous êtes mastic.
  2. Collez la clé publique dans votre /home/youruser/.ssh/authorized_keys du côté serveur, sur le serveur sur lequel vous utilisez mastic, connectez-vous.
  3. Rendre la clé privée accessible au mastic dans les paramètres de mastic Connexion-> SSH-> Auth
  4. Ajoutez la clé privée en spécifiant le fichier de clé privée sous: "Fichier de clé privée pour l'authentification".
  5. Enregistrez les paramètres de connexion du mastic.

Ensuite, vous pouvez double-cliquer sur votre connexion via un mastic, et cela devrait vous amener directement au terminal sans saisir le nom d'utilisateur / mot de passe.

Donc, maintenant, vous pouvez connecter une connexion à mastic sur cette connexion avec une combinaison de clavier comme F6. Donc, quand le wifi se passe mal et que vous êtes lâché. Vous écrasez F6 et vous êtes de nouveau connecté.

MAIS vous perdez toujours l'état de votre terminal! Comment réparer ça? Utilisez le programme "screen". 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 comment faire cela: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

C'est un problème de taper screen et reconnectez-vous 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 à mastic se gèle. Cela ressemble à ceci: Vous faites un ronflement de mépris, écrasez Alt + F4 pour fermer le mastic, Mash down F6. Et en 6 secondes, vous êtes de retour là où vous vous êtes arrêté.

Une solution encore meilleure, en théorie

En théorie, vous pouvez écrire tout ce processus ci-dessus, afin que le terminal détecte le moment où il a été supprimé et effectue toutes les étapes ci-dessus pour la restauration de la connexion Internet. Si quelqu'un connaît un programme, cela me le fera automatiquement savoir. Ce serait chouette.

Sources:

http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-keepalive

http://rafaelwolf.com/?p=516


52
2018-06-25 18:52



Bonjour, je le fais, mais je continue à avoir l'erreur de connexion du logiciel fermée - tuskiomi


Dépannage de l'erreur de réseau PuTTY

Software caused connection abort

Lisez ce que PuTTY a à dire sur l'erreur

Il s'agit d'une erreur générique générée par le code réseau Windows lorsqu'il détruit une connexion établie pour une raison quelconque. Par exemple, cela peut se produire si vous retirez le câble réseau par l'arrière d'un ordinateur connecté à Ethernet ou si Windows a d'autres raisons similaires de croire que le réseau entier est devenu inaccessible.

Windows génère également cette erreur si elle a abandonné sur la machine à l'autre extrémité de la connexion en y répondant. Si le réseau entre votre client et le serveur tombe en panne et que votre client essaie ensuite d'envoyer des données, Windows essaiera plusieurs fois d'envoyer les données, puis abandonnera et supprimera la connexion. En particulier, cela peut se produire même si vous n’avez rien saisi, si vous utilisez SSH-2 et que PuTTY tente de ré-échanger des clés.

(Cela peut également se produire si vous utilisez des Keepalives dans votre connexion. D'autres personnes ont signalé que les Keepalives corrigent cette erreur pour eux (il y a des avantages et des inconvénients de Keepalives.))

Nous ne sommes au courant d'aucune raison pour laquelle cette erreur pourrait se produire et représenter 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 apporter des preuves à cela, utilisez un client SSH différent (http://kitty.9bis.net) et voir si le problème se produit également. Cela aura probablement pour effet d'isoler le problème de PuTTY.

Connexion Internet suspecte suspecte

Le problème peut être la connexion Internet inégale. Connectivité Internet La surveillance de la disponibilité d'une connexion Internet est un bon moyen de déterminer si votre FAI perd des paquets et est responsable de la panne de PuTTY. Obtenez des logiciels qui testent la disponibilité d'une connexion Internet. Par exemple, http://code.google.com/p/internetconnectivitymonitor/. Les déconnexions fréquentes et longues d'Internet constituent une violation des exigences du service ISP. Si tel est le cas, il sera difficile de prouver que c'est la faute du FAI, car le support technique blâme automatiquement ces types de problèmes sur votre ordinateur, votre système d'exploitation, votre routeur et votre câblage. Si vous utilisez le câble Internet et que vous vivez dans les boonie, il est possible que le matériel défectueux des maisons de votre voisin envoie des données statiques pendant quelques secondes / minutes au moment de la 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 pour les fournisseurs de services Internet de remplacer leur matériel est si élevé qu’ils ne le font souvent que s’il ya suffisamment d’abonnés dans une région pour garantir le coût.

Suspecter le routeur câblé / sans fil

Vous connectez-vous via un routeur filaire / sans fil? Quel âge a-t-il? Votre routeur peut être le problème. Les anciennes technologies sans fil et câblées peuvent avoir des connexions anciennes et sporadiques 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 filaire et / ou un routeur différent pour voir si cela résout le problème. J'ai eu un routeur sans fil Linksys subir cette mort lente et les connexions de chute et les redémarrer.

Suspecter le système d'exploitation fournissant la connexion SSH

L'ordinateur auquel vous vous connectez avec SSH dispose d'une stratégie pour le nombre de secondes nécessaire 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 que vous utilisez qui fournit SSH.

Si vous utilisez PuTTY via une machine virtuelle

Si vous utilisez PuTTY en passant par une machine virtuelle, il peut exister une stratégie sur la machine virtuelle qui brise votre connexion SSH au serveur lorsqu'elle pense être inactive. L'augmentation de ces valeurs dépend du logiciel de la machine virtuelle et du système d'exploitation que vous utilisez.

Si la connexion Internet est incorrecte, les solutions de connexion au client SSH:

Si votre FAI fournit une connexion instable, vous pourriez rendre les déconnexions moins douloureuses avec "autshin SSH". Ce que vous faites est de générer une clé publique et privée. Et vous indiquez à votre serveur étranger de laisser automatiquement entrer quiconque fournit une clé privée précise. Cela ne résout pas complètement votre problème, mais lorsque la panne d'Internet survient, il vous suffit de fermer la fenêtre, de double-cliquer sur une icône et vous êtes immédiatement ramené à la ligne de commande de votre dossier personnel sans saisir de nom d'utilisateur / mot de passe.

Cela vous aidera à cela: Existe-t-il un moyen de se connecter automatiquement dans PuTTY avec un mot de passe?


8
2017-08-20 13:35





Dans une invite de commande élevée, exécutez les opérations suivantes:

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 alors vous aurez des problèmes. Désactivez-le et tout devrait fonctionner comme auparavant:

C:\Windows\system32>netsh int tcp set global autotuninglevel=disabled

4
2018-02-08 19:08



pouvez-vous expliquer pourquoi cela fonctionne / ce qu'il fait? - Eiyrioü von Kauyf
support.microsoft.com/kb/947239 voici la description de cette - bksi


Onglet Connexion: rester en vie défini à "5" secondes et activé

Mais plus important:

Connexion -> SSH -> Kex, Max minutes avant rekey: "2" (la valeur par défaut est 60).

Mon PuTTY perdait sa clé après un certain temps, provoquant le dépassement de délai. La suppression de cette valeur à "2" minutes a résolu le problème. Je reste connecté indéfiniment maintenant.


2
2017-08-24 09:09





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 PuTTY (Keepalives, etc.) mais cela n'a pas aidé du tout.

Enfin, j'ai trouvé la solution pour mon cas. J'ai enregistré des vidages TCP à la fois sur le client et sur le serveur. J'ai découvert que pendant 25-30 secondes avant de déconnecter, il y a plusieurs retransmissions de segments TCP dans le dump du client (à la fois du côté 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 pendant cette période, même RST. Cela signifie que, de temps en temps, aucun segment TCP du client n'est livré au serveur et que cette période est d'environ 30 à 60 secondes. J'ai enregistré le cas à plusieurs reprises et il y avait toujours des retransmissions et un RST final de PuTTY. Probablement quelque part sur la route, les paquets ont été abandonnés par les équipements du réseau.

Pour résoudre le 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 PuTTY de se déconnecter trop rapidement. La variable est 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ TcpMaxDataRetransmissions'. J'ai ajouté cette variable manuellement, elle n'était pas initialement définie dans le registre de Windows. Ça a aidé! Maintenant, je vois que PuTTY est suspendu de temps en temps, mais il revient toujours au travail.

Pour résoudre le problème: 1. Enregistrez un vidage TCP et recherchez les retransmissions et le RST avant de vous déconnecter. 2. Si vous trouvez les mêmes segments de retransmission / RST, ajustez le nombre de tentatives sur un serveur ou un 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.


2
2017-10-29 16:48





L'erreur Erreur réseau: Abandon de la connexion causée par le logiciel de PuTTY est le résultat s'il y a un Conflit 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 Tarte aux framboises qui a la même adresse IP attribuée par le DHCP serveur en tant que périphérique / ordinateur non fiable configuré manuellement pour utiliser la même adresse IP.)

Dans ce cas particulier, il pourrait s'agir d'un conflit d'adresse IP localement sur l'ordinateur Windows 7 ou avec un autre périphérique du réseau. Wireshark peut être utilisé pour localiser avec succès ce type d'erreur.


2
2017-11-26 09:57





L'erreur 10053 WSAECONNABORTED (Abandon de connexion causé par logiciel.) Est un générique Winsock erreur pouvant être émise pour diverses raisons.

le explication officielle dit:

Cette erreur peut survenir lorsque le système de réseau local interrompt une connexion, par exemple lorsque Winsock ferme une connexion établie après que la retransmission des données échoue (le récepteur ne reconnaît jamais les données envoyées sur un socket de flux de données).

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


1
2017-08-20 13:41





J'ai rencontré le même problème soit avec un WinSCP script ou console graphique. Enfin, j'ai trouvé que cela était lié à la vitesse (vitesse Internet - notre serveur est sur Internet). J'ai déplacé le script à un emplacement différent sur le réseau, sur un site différent, et les interfaces graphiques et les scripts ne se sont pas bien passées.

Il a été trié après beaucoup d'analyse et de tri.


1
2018-03-12 16:11





Vous devez activer TCPKeepAlive sur Linux.

Il est expliqué dans la FAQ de PuTTy sur le site Web lorsque vous recherchez cette erreur.


0
2018-06-09 22:30



Mais la valeur par défaut pour TCPKeepAlive est yes. Cependant, je l'ai activé. Mais le délai de connexion est le premier problème. Des idées? - Robert
J'ai désactivé le pare-feu du serveur Linux et le pare-feu du client Windows-7, mais la connexion est toujours terminée! Vraiment énervant! - Robert
Il semble parfois que je puisse me connecter mais parfois, la connexion est un délai d'attente! Je ne sais vraiment pas pourquoi. Il me rend fou! - Robert


Si la machine virtuelle est en cours d'exécution sur votre matériel local, désactivez les paquets actifs.


0
2018-01-10 17:23



Pouvez-vous développer la réponse? Peut-être donner des instructions pour les futurs visiteurs? - Canadian Luke
J'ai la situation opposée en tant que OP - ma VM est le client ssh qui se connecte à l'hôte et le client se déconnecte fréquemment. Désactiver le maintien en vie semble avoir résolu le problème. Je me demande pourquoi. - Raman