it-swarm.com.de

packet_write_wait Pipe gebrochen, selbst wenn das Top läuft?

Dieser blutige Fehler lässt meine Kopfschmerzen von Tag zu Tag größer werden. Ich habe noch nie eine Situation wie diese erlebt.

Nun, nachdem ich mich erfolgreich bei SSH authentifiziert habe und ein paar Dinge getan habe, wird meine SSH-Verbindung plötzlich unterbrochen !!?

Hier ist meine Fehlermeldung: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Ich wünschte, meine Fehlermeldung würde so aussehen: Write Failed: broken pipe viel, glaub mir!

Ich habe eine Menge Auflösung im Internet ausprobiert, wie ServerAliveInterval, ServerAliveCountMax, ClientAlive ... hinzugefügt.

Jemand sagte: Schalten Sie Ihr TCPKeepAlive auf Nein, fügte ServerAlive hinzu. Ich habe das auch gemacht aber immer noch den gleichen Fehler.

Bis zu diesem Moment gibt es kein Glück für mich.

Jede Hilfe wird geschätzt.

29
Toan Nguyen

Liebe Leser von 2018 und später,

Lassen Sie mich Ihnen einen Kommentar von MelBurslan zeigen,

Wenn Sie sich in einer Unternehmensumgebung befinden, erkundigen Sie sich bei Ihren Firewall-Administratoren, ob diese nach einer Änderung in diesem Fall Regeln aktualisiert und/oder die Firewall neu gestartet haben. Wenn es einem Ihrer persönlichen Server passiert, müssen Sie weitere Informationen darüber bereitstellen, was Sie auf der SSHD-Serverseite getan haben, als dies geschah. Eine unterbrochene Leitung bedeutet im Allgemeinen, dass aus irgendeinem Grund eine Netzwerkunterbrechung aufgetreten ist.

Wenn Sie also versuchen, ssh [email protected] Über ein VPN (Unternehmensumgebung) zu verwenden. Dann muss dieser Fehler immer wieder bei Ihnen sein.

Die einzige Lösung , die ich bisher gefunden habe, ist mobile-Shell . Danke, wer es erstellt hat.

Sie müssen mosh-server Auf Ihrem Ziel (dem Server, auf den Sie ssh'ed möchten) und mosh-client Auf Ihrem Host-Computer installieren.

Es wird automatisch wieder verbunden, wenn Ihre Pakete verloren gehen. Das ist ziemlich cool und entspricht all unseren Anforderungen, denke ich.

Update 03/2020:

Wenn Sie mosh-server Nicht auf Ihren Servern installieren können, können Sie mein Skript hier verwenden: https://github.com/ohmybash/oh-my-bash/blob/master/tools/ autossh.sh

Die Verbindung zu SSH wird automatisch automatisch wiederhergestellt, wenn die SSH-Sitzung beendet ist.

Viel Spaß beim Ssh'ing!

8
Toan Nguyen

Ich habe festgestellt, dass es sich bei meinem VMware Guest-Setup um ein IPQoS-Optionsproblem handelt. Auf der VM habe ich den Wert ~/.ssh/config für IPQoS aus dem Standardwert "IPQoS af21 cs1" als Daten mit geringer Latenz für interaktive erste und geringerer Aufwand für nicht interaktive für die zweite festgelegt Einen neuen Wert für af21 festzulegen war meine Lösung:

Host *
     IPQoS throughput

Hat für mich funktioniert, ansonsten funktioniert ja auch MoSH, aber mosh behandelt mein Proxy-Setup nicht auf bequeme Weise, sodass ich mich an die ProxyJump-Befehle halte

4
rupert160

Ich habe diesen Fehler immer wieder erhalten, wenn ich eine Remoteverbindung zu einem Server in meinem Büro hergestellt habe. Wir verwenden kein VPN, daher werden alle externen Verbindungen über einen Proxyserver ausgeführt. Die IT-Abteilung hatte den folgenden SSH-Konfigurationseintrag bereitgestellt, den ich direkt in mein ~/.ssh/config:

Host xx.xx.xx.xx
  ProxyCommand ssh [email protected] exec netcat -w 5 %h %p

Ich weiß nicht, warum sie die -w 5, da dies zu einer sehr kurzen Zeitüberschreitung von 5 Sekunden Inaktivität führt, bevor die Verbindung unterbrochen wird. Entfernen oder Erhöhen des -w Parameter beseitigt das Problem (ebenso wie das Umschalten auf nur ProxyJump [email protected], was die IT jetzt empfiehlt).

1
knowah

Stellen Sie zunächst sicher, dass Ihr Problem nicht mit diesem zusammenhängt.

Wenn nicht und das Problem weiterhin besteht, lesen Sie weiter.

Ich habe dieses Problem ebenfalls erlebt und ein paar Tage lang versucht, es zu lösen.

Wie angegeben, löst das Spielen mit SSH KeepAlive-Parametern oder Kernel TCP -Parametern (TCPKeepAlive ein/aus) das Problem nicht.

Nachdem ich mit USB zu Ethernet-Treibern und TCP dump) gespielt hatte, stellte ich fest, dass das Problem auf den Kernel 4.8 zurückzuführen war. Ich stellte die Quelle (Sendeseite) auf 4.4 LTS um und das Problem verschwand (rsync, scp haben wieder gut funktioniert). Die Zielseite kann auf 4.8 bleiben, wenn Sie möchten, in meinem Anwendungsfall hat dies funktioniert (getestet).

Auf der technischen Seite können wir das Problem dank des von mir erstellten Wireshark-Dumps ein wenig eingrenzen. Wir können sehen, dass der TCP Kanal des SSHv2-Protokolls zurückgesetzt wird (RST-Flag von TCP auf 1 gesetzt), wodurch die Verbindung abgebrochen wird. Ich nicht Ich kenne die Ursache des RST noch. Dafür muss ich eine Halbierung von 4.8.1 auf 4.8.11 vornehmen. enter image description here

Ich sage nicht, dass Ihr Problem speziell auf den Kernel 4.8 zurückzuführen ist, sondern auf wrt. An dem Tag, an dem Sie Ihre Frage/Nachricht gepostet haben, haben Sie möglicherweise eine Kernel-Version verwendet, die tatsächlich fehlerhaft war.

Beantwortet zunächst am StackOverflow .

1
wget

ssh -o IPQoS=throughput [email protected]{ip}

1
vicky penkova

Öffnen Sie die Datei ssh.config auf dem Zielserver mit dem folgenden Befehl:

Sudo nano /etc/ssh/ssh.config

Fügen Sie die folgenden Zeilen am Ende dieser Datei hinzu

ClientAliveInterval 300

ClientAliveCountMax 2

drücken Sie Strg + o und geben Sie ein.

Sudo Neustart

Das hat bei mir akut funktioniert. Ich war in der gleichen Situation. Versuchte dies und das, aber folge einfach diesen Schritten. Nur das. Ich hoffe es wird auch für dich funktionieren.

0
DonFeraRRi