packet_write_wait Pipe cassée même en laissant le haut fonctionner?

26

Cette erreur sanglante rend mon mal de tête de plus en plus gros chaque jour. Je n'ai jamais rencontré une même situation comme cette fois.

Eh bien, après m'être authentifié avec succès en SSH, faire quelques trucs puis ma connexion SSH a été interrompue soudainement !!?

Voici mon message d'erreur: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Je souhaitais que mon message d'erreur ressemble à ceci: Write Failed: broken pipebeaucoup, croyez-moi!

J'ai essayé des tonnes de résolution sur Internet comme ServerAliveInterval, ServerAliveCountMax, ClientAlive ....

Quelqu'un a dit: Mettez votre TCPKeepAlive sur non, a ajouté idiot de ServerAlive bllah blah. J'ai fait ça aussi mais toujours la même erreur.

Il n'y a pas de chance pour moi jusqu'à ce moment.

Toute aide sera appréciée.

ssh

— Toan Nguyen
source

2

Si vous êtes dans un environnement d'entreprise, vérifiez auprès de vos administrateurs de pare-feu et voyez s'ils mettaient à jour les règles et / ou redémarraient le pare-feu après une sorte de changement lorsque cela se produit. Si cela arrive à un de vos serveurs personnels, vous devez fournir plus d'informations sur ce que vous faisiez du côté du serveur sshd, lorsque cela s'est produit. Broken pipesignifie généralement qu'il y a eu une déconnexion du réseau pour une raison quelconque.

— MelBurslan

Je viens de déménager et cela se produit constamment avec ma nouvelle connexion. Cox Cable est mon FAI, et j'ai un modem câble Netgear C6300BD fonctionnant avec les paramètres par défaut de l'installation. Cela se produisait à mon ancien emplacement et je n'ai jamais pu le résoudre. Cela a duré des mois et a finalement cessé de se produire. J'ai oublié à quel point c'était misérable et insoluble jusqu'à aujourd'hui.

— T. Brian Jones

Je ressens ta douleur. Je suis venu ici en dernier recours avant de claquer tout mon matériel en petits morceaux. N'est-ce pas censé être un protocole assez simple?

— DerpyNerd

J'ai eu la même erreur sur Linux virtualisé, le problème a résolu en changeant l'adaptateur Ethernet en ponté

— Abel Barrios

8

Chers lecteurs de 2018 et suivants,

Permettez-moi de vous montrer un commentaire de MelBurslan,

Si vous êtes dans un environnement d'entreprise, vérifiez auprès de vos administrateurs de pare-feu et voyez s'ils mettaient à jour les règles et / ou redémarraient le pare-feu après une sorte de changement lorsque cela se produit. Si cela arrive à un de vos serveurs personnels, vous devez fournir plus d'informations sur ce que vous faisiez du côté du serveur sshd, lorsque cela s'est produit. Un tuyau cassé signifie généralement qu'il y a eu une déconnexion du réseau pour une raison quelconque.

Donc, fondamentalement, si vous essayez d'utiliser ssh username@0.0.0.0un VPN (environnement d'entreprise). Ensuite, cette erreur doit être là avec vous encore et encore.

La seule solution que j'ai trouvée jusqu'à présent est le shell mobile . Merci qui l'a créé.

Vous devrez installer mosh-serversur votre cible (le serveur sur lequel vous souhaitez vous connecter) et mosh-clientsur votre machine hôte.

Il se reconnectera automatiquement lorsque vos paquets seront perdus, c'est plutôt cool et répond à tous nos besoins, je pense.

Bonne ssh'ing!

— Toan Nguyen
source

3

J'ai découvert qu'il s'agissait d'un problème d'option IPQoS sur ma configuration d'invité VMware. Sur la machine virtuelle, j'ai défini la valeur ~ / .ssh / config pour IPQoS à partir de la valeur par défaut de "IPQoS af21 cs1" étant des données à faible latence pour le premier interactif et un effort moindre pour le non-interactif pour le second. Définir une nouvelle valeur pour af21 était ma solution:

Host *
     IPQoS throughput

Fonctionné pour moi, sinon oui MoSH fonctionne également, mais mosh ne gère pas ma configuration Proxy de manière pratique, donc je m'en tiens aux commandes ProxyJump dans

— rupert160
source

Amusant, cela fonctionne en ligne de commande (comme vous l'expliquez dans votre post sur ubuntu) mais pas dans le fichier de configuration 8-D

— aurelien

1

Tout d'abord, assurez-vous que votre problème n'est pas lié à celui-ci .

Si ce n'est pas le cas et que le problème persiste, lisez la suite.

J'ai également rencontré ce problème et j'ai passé quelques jours à essayer de le bissecter.

Comme spécifié, jouer avec les paramètres SSH KeepAlive ou les paramètres TCP du noyau (TCPKeepAlive on / off) ne résout pas le problème.

Après avoir joué avec les pilotes USB vers Ethernet et le vidage TCP, j'ai réalisé que le problème était dû au noyau 4.8. J'ai basculé la source (côté envoi) sur 4.4 LTS et le problème a disparu (rsync, scp fonctionnait bien à nouveau). Le côté destination peut rester sur 4.8 si vous le souhaitez, dans mon cas d'utilisation, cela fonctionnait (testé).

Sur le plan technique, nous pouvons affiner un peu le problème grâce à la décharge de wirehark ci-dessous que j'ai faite. Nous pouvons voir que le canal TCP du protocole SSHv2 est en cours de réinitialisation (indicateur RST de TCP défini sur 1) provoquant l'abandon de la connexion. Je ne connais pas encore la cause de la TVD. J'ai besoin de faire une bissection de 4.8.1 à 4.8.11 pour cela.

Je ne dis pas que votre problème est spécifiquement dû au noyau 4.8, mais wrt. la date à laquelle vous avez publié votre question / message, vous utilisiez peut-être une version du noyau qui était en fait boguée.

Répondu initialement sur StackOverflow .

— wget
source

Le noyau n'est pas le problème, car j'utilisais 4.4 LTS tout le temps. @MelBursan a répondu au vrai problème dans le commentaire de la question. Ma connexion Internet via VPN, c'est pourquoi. Solution: mosh.org

— Toan Nguyen

@ToanNguyen Ok. De cette façon, pourriez-vous s'il vous plaît mettre son commentaire comme réponse à votre question et le marquer comme fixe? :-) Si vous avez trouvé les raisons techniques pour lesquelles vous aviez besoin de mosh, veuillez les ajouter également :-). De mon côté, j'ai également des connexions VPN et elles fonctionnaient parfaitement sans mosh.

— wget

J'y reviens. Le problème n'était pas dû à un noyau buggé, mais à un pilote buggé, en particulier la partie dédiée au déchargement de la somme de contrôle matérielle. Voir ce fil pour plus d'informations .

— wget

Cela résout-il votre problème?

— Toan Nguyen

@ToanNguyen En fait, la dernière fois que j'ai eu ce problème, j'ai simplement rétrogradé le noyau et cela fonctionnait à nouveau. Maintenant, j'ai simplement désactivé le déchargement de la somme de contrôle hw, sans déclasser quoi que ce soit et cela a résolu le problème, oui.

— wget

1

ssh -o IPQoS=throughput user@{ip}

— vicky penkova
source

Rien n'indique que l'utilisateur utilise macOS ou qu'il essaie de se connecter en tant que root.

— Kusalananda

Vous avez raison! Cependant, j'ai testé la commande avec un utilisateur différent de «root» et sous Windows. Fonctionne encore!

— vicky penkova

0

Ouvrez le fichier ssh.config sur le serveur cible avec la commande ci-dessous:

sudo nano /etc/ssh/ssh.config

Ajoutez les lignes ci-dessous à la fin de ce fichier

ClientAliveInterval 300

ClientAliveCountMax 2

appuyez sur Ctrl + o et entrez.

redémarrage sudo

Cela a vraiment fonctionné pour moi. J'étais dans la même situation. J'ai essayé ceci et cela, mais suivez simplement ces étapes. Seulement ça. J'espère que cela fonctionnera aussi pour vous.

— DonFeraRRi
source