このクソミスは私の頭痛を毎日もっとひどくしました。私はこのような状況に直面したことはありません。
さて、SSHで正常に認証した後、いくつかのことをしましたが、突然SSH接続が失われました！ ！ ？
私のエラーメッセージは次のとおりです。packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe
私は私のエラーメッセージを次のように表示したいと思います。Write Failed: broken pipeたくさん、私を信じてください！
私はServerAliveInterval、ServerAliveCountMax、ClientAliveを追加するなど、インターネット上で多くのソリューションを試しました...
一部の人々は次のように言います。 TCPKeepAliveをnoに変更し、ServerAliveを追加するなどの愚か者。私もこれをしましたが、まだ同じエラーが発生しました。
これまで私は幸運だったことがなかった。
どんな助けでも大変感謝します。
答え1
2018年以降、読者の皆さん、
MelBurslanのレビューをお見せします。
企業環境にいる場合は、ファイアウォール管理者に連絡してこれが発生した場合は、ルールが更新されていることを確認するか、変更を適用してファイアウォールを再起動してください。プライベートサーバーでこれが発生した場合は、この問題が発生したときにsshdサーバー側で行った操作に関する追加情報を提供する必要があります。破損したパイプは、通常、何らかの理由でネットワークがダウンしていることを意味します。
デフォルトでは、VPN（企業環境）で使用したい場合です。そうすれば、この間違いはあなたに残るでしょう。ssh [email protected]
唯一の解決策今まで見つけたことは携帯電話ケース。作った人に感謝します。
mosh-serverターゲット（sshで接続するサーバー）とホストにインストールするmosh-client必要があります。
パケットが失われると自動的に再接続されますが、これは非常にクールで、私たちのすべての要件に適していると思います。
2020年3月の更新：
mosh-serverサーバーにインストールできない場合は、ここで私のスクリプトを使用できます。https://github.com/ohmybash/oh-my-bash/blob/master/tools/autossh.sh
SSH セッションの有効期限が切れると、自動的に SSH に再接続されます。
楽しい時間をお過ごしください！
答え2
これがVMwareゲスト設定のIPQoSオプションに問題があることがわかりました。 VMでは、IPQoSの~/.ssh/config値をデフォルト値の「IPQoS af21 cs1」に設定しました。 1つ目は待ち時間の短い対話型データ、2つ目は非対話型の低ワークロードに設定しました。 af21の新しい値を設定することが私の解決策でした。
Host *
IPQoS throughput
私に適しています。それ以外の場合はMoSHも機能しますが、moshはプロキシ設定を便利な方法で処理しないため、ProxyJumpコマンドを使用します。
答え3
まず、あなたの質問が以下に関連していないことを確認してください。これ。
それ以外の場合でも問題が解決しない場合は、必ずお読みください。
私もこの問題に直面し、これを解決するために数日を過ごした。
指定したSSH KeepAliveパラメータまたはカーネルTCPパラメータ（TCPKeepAliveのオン/オフ）を使用しても問題は解決されません。
USB-EthernetドライバとTCPダンプを使用した後、問題がカーネル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。質問/メッセージを投稿した日付に実際にバグのあるカーネルバージョンを使用していた可能性があります。
元の答え：スタックオーバーフロー。
答え4
実際に私の問題に対する解決策を見つけました。 LinuxユーザーがSELinuxユーザーにマップされていることを確認してください。
説明すると、デフォルトでは、Linuxで作成されたすべてのユーザーは同じunconfined_u SElinuxユーザーコンテキストを持ちます。これは、一般的なLinuxユーザーがrootが実行する操作を実行できることを意味します。Linux ユーザーと SElinux ユーザー間の明示的な変更またはマッピングにより、ssh が正しく機能しないことがあります。
シナリオ：ここで一般的なLinuxユーザーを作成します。 ユーザーを追加 -m USER1
USER1は現在、一般的なLinuxユーザーです。デフォルトでは、このLinuxユーザーUSER1はSElinux unconfined_u USER1にマップされ、デフォルトで作成されたすべてのユーザーはSElinux unconfined_uの下にあります。 rootユーザーもこのコマンドで確認します。 管理者ログイン -l
一般的な Linux USER1 を SElinux sysadm_u ユーザーにマッピングすることにした場合、USER1 に ssh を使用することはできません。 Semanage ログイン -m -s sysadm_u -r s0 USER1
USER1 は SELinux sysadm_u ユーザーにマップされ、SSH ユーティリティを使用できなくなりました。
この問題をどのように解決しますか？さて、Linuxユーザー「USER1」をSELinuxユーザー「user_u」にマップすると、実際に問題が解決します。
ユーザーを SElinux sysadm_u にマップしないでください。