packet_write_wait topを実行したままでもパイプが壊れていますか?


26

この血まみれのエラーにより、私の頭痛はますます大きくなっています。今回のような状況に出会ったことはありません。

まあ、私はSSHに正常に認証された後、いくつかのことをして、SSH接続が突然切断されました!!?

エラーメッセージは次のとおりです。 packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

エラーメッセージが次のようになることを望みWrite Failed: broken pipeました。

追加されたServerAliveInterval、ServerAliveCountMax、ClientAliveのように、インターネットで大量の解像度を試しました。

誰かが言った:あなたのTCPKeepAliveをnoに変えて、ServerAlive bllah blahばかを追加しました。私もそれをしましたが、それでも同じエラーです。

この瞬間まで私には運がありません。

どんな助けも感謝します。


2
企業環境にいる場合は、ファイアウォール管理者に確認し、ルールが更新されているか、何らかの変更が行われた後にファイアウォールを再起動しているかどうかを確認してください。自分の個人サーバーで発生している場合、これが発生したときにsshdサーバー側で何をしていたかに関する詳細情報を提供する必要があります。Broken pipe通常、何らかの理由でネットワークの切断があったことを意味します。
メルバースラン16

私は引っ越したばかりで、これは私の新しい接続で絶えず起こっています。Cox Cableは私のISPであり、Netgear C6300BDケーブルモデムをインストール時のデフォルト設定で実行しています。これは以前の場所で発生していたため、解決できませんでした。それは数ヶ月続き、最終的には発生しなくなりました。今日までそれがどれほど悲惨で解決不能であったかを忘れていました。
T.ブライアンジョーンズ

あなたの痛みが分かります。私はすべてのハードウェアを小さな断片に平手打ちする前に、最後の手段としてここに来ました。これはかなり単純なプロトコルではないでしょうか?
DerpyNerd

私は仮想化Linux上で同じエラーがあったが、問題は、ブリッジへのイーサネットアダプタを変更解く
アベルバリオス

回答:


8

2018年以降の読者の皆様、

MelBurslanからのコメントをお見せしましょう。

企業環境にいる場合は、ファイアウォール管理者に確認し、ルールが更新されているか、何らかの変更が行われた後にファイアウォールを再起動しているかどうかを確認してください。自分の個人サーバーで発生している場合、これが発生したときにsshdサーバー側で何をしていたかに関する詳細情報を提供する必要があります。パイプの破損は、通常、何らかの理由でネットワークが切断されたことを意味します。

基本的に、ssh username@0.0.0.0VPN(企業環境)経由で使用しようとしている場合。その後、このエラーは何度も発生するはずです。

私がこれまでに見つけた唯一の解決策mobile-shellです。作成者に感謝します。

mosh-serverターゲット(sshしたいサーバー)とmosh-clientホストマシンにインストールする必要があります。

パケットが失われると自動的に再接続します。これは非常にクールで、すべてのニーズに合っていると思います。

ハッピーssh'ing!


3

VMwareゲストのセットアップでのIPQoSオプションの問題であることがわかりました。VMでは、IPQoSの〜/ .ssh / config値をデフォルトの「IPQoS af21 cs1」から設定しました。これは、最初は対話型では低遅延データであり、2番目では非対話型で少ない労力です。私の解決策はaf21に新しい値を設定することでした:

Host *
     IPQoS throughput

私のために働いた、そうでなければはいMoSHも働いていますが、moshはプロキシ設定を便利な方法で処理しないので、ProxyJumpコマンドを


楽しい、コマンドラインでその作品(あなたがUbuntuで、あなたの記事で説明したように)ではなく、設定ファイル8-Dで
オーレリアン

1

まず、あなたの問題がこれに関係しいないことを確認してください。

そうでなくても問題が解決しない場合は、先に進んでください。

私もこの問題を経験し、数日かけてそれを二分しようとしました。

指定されているように、SSH KeepAliveパラメーターまたはカーネルTCPパラメーター(TCPKeepAlive on / off)を使用しても問題は解決しません。

イーサネットドライバーとTCPダンプへのusbで遊んだ後、この問題はカーネル4.8が原因であることに気付きました。ソース(送信側)を4.4 LTSに切り替えたところ、問題はなくなりました(rsync、scpは再び正常に機能しました)。必要に応じて、宛先側を4.8のままにすることができます。私の使用例では、これは機能していました(テスト済み)。

技術的な面では、私が作成した下のWiresharkダンプのおかげで、問題を少し絞り込むことができます。SSHv2プロトコルのTCPチャネルがリセットされ(TCPのRSTフラグが1に設定されている)、接続が中止されることがわかります。RSTの原因はまだわかりません。そのためには、4.8.1から4.8.11に二分する必要があります。ここに画像の説明を入力してください

あなたの問題は特にカーネル4.8が原因であるとは言いませんが、wrtです。質問/メッセージを投稿した日付、実際にはバグのあるカーネルバージョンを使用している可能性があります。

最初にStackOverflowで回答しました。


常に4.4 LTSを使用していたため、カーネルは問題ではありません。ここでの本当の問題は、質問のコメントで@MelBursanによって回答されました。VPNを使用した私のインターネット接続、それが理由です。ソリューション:mosh.org
Toan Nguyen

@ToanNguyenわかりました。そうすれば、あなたの質問への回答として彼/彼女のコメントを入れて、修正済みとしてマークしてください。:-) moshが必要な技術的理由を見つけた場合は、それらも追加してください:-)。私の側では、VPN接続もあり、これらはモッシュなしで問題なく動作していました。
wget

私はこれに戻ってきています。問題の原因は、バグのあるカーネルではなく、バグのあるドライバー、特にハードウェアチェックサムオフロード専用の部分です。詳細については、このスレッドを参照してください
-wget

それはあなたの問題を解決しますか?
トアングエン

@ToanNguyen実際、この問題が発生した前回は、単にカーネルをダウングレードしただけで、再び機能していました。さて、何もダウングレードせずに、単純にハードウェアチェックサムオフロードを無効にして、問題を解決しました。
-wget

1

ssh -o IPQoS=throughput user@{ip}


ユーザーがmacOSを使用していることや、rootとしてログインしようとしていることを示す兆候はありません。
クサラナンダ

あなたは正しいです!ただし、「root」とは異なるユーザーおよびWindowsでコマンドをテストしました。それでも動作します!
ヴィッキーペンコバ

0

以下のコマンドを使用して、ターゲットサーバーでssh.configファイルを開きます。

sudo nano /etc/ssh/ssh.config

そのファイルの最後に以下の行を追加します

ClientAliveInterval 300

ClientAliveCountMax 2

Ctrl + oを押して入力します。

sudo reboot

これは実際に私のために働いた。私も同じ状況でした。これを試してみましたが、次の手順に従ってください。これだけ。それがあなたにとってもうまくいくことを願っています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.