☰

ssh接続「client_loop：切断された送信：切断されたパイプ」または「接続のリセット」ポート22"

tag-icon • tag-icon ssh port-forwarding macos
ssh接続「client_loop：切断された送信：切断されたパイプ」または「接続のリセット」ポート22"

私は数ヶ月間SSHを使用してリモートサーバーにアクセスしてきましたが、最近は信頼性の高い接続を確立するのに問題があります。時々ログインできず、「ポート22を介して接続がリセットされました」というメッセージが表示されます。あるにもかかわらず）。アイドル状態ではありません）。

私の ~/.ssh/config ファイルには次のものがあります。

Host *  

     ServerAliveInterval 300
     ServerAliveCountMax 2
     TCPKeepAlive yes

私の/etc/ssh/sshd_configファイルには次のものがあります。

#ClientAliveInterval 300
#ClientAliveCountMax 3

私は最近xfinityプランをより高速にアップグレードしましたが、問題が発生し始めました。しかし、Xpinityは問題は私にあると主張した。私のルームメイトも同じSSHの問題に直面しています。

私が逃したものはありますか？どんな助けでも大変感謝します！ （私はMac上で動作しています）

答え1

~/.ssh/config ファイルを編集して同じ問題を解決しました。

Host *
    ServerAliveInterval 20
    TCPKeepAlive no

やる気

TCPKeepAlive noこれは、「サーバーに接続保持メッセージを送信しない」を意味します。逆 TCPKeepAlive yes が設定されている場合、クライアントは keepalive メッセージをサーバーに送信します。接続の終了を維持するには応答が必要です。。サーバーが失敗したか、再起動したかなどを検出します。問題は、クライアントとサーバー間の接続が短時間中断された場合（不安定なネットワーク接続のため）、Keepaliveメッセージが失敗し、クライアントが「壊れたパイプライン」で接続を終了することです。 。

この設定は、TCPKeepAlive noユーザーが接続がまだ良好であるという証拠を要求するまで、接続がまだ良好であると仮定するようにクライアントに指示します。これは、SSH用語がバックグラウンドでアイドル状態の間、一時的な接続の中断が接続を終了しないことを意味します。

答え2

Davidの答えはい、しかしより包括的な解決策は以下に説明されています。

この問題はクライアントまたはサーバーで解決できます。

どこでやっているのはどうすればわかりますか？

  • SSH経由で複数のサーバーに接続する場合は、コンピュータで設定してください。

  • システム管理者であり、複数のユーザーがSSH接続が頻繁に発生すると不平を言っている場合は、サーバーでこれを設定できます。

顧客

サーバーに接続するときは、次の-oオプションを使用します。

ssh -o ServerAliveInterval=600 [email protected]

この値は600600秒、つまり10分を表します。

または、SSH構成ファイルに以下を追加します。

  1. SSH 構成ファイルがない場合は作成します。 
    touch ~/.ssh/config
  2. 権限設定： 
    chmod 600 ~/.ssh/config
  3. 構成ファイルにパラメーターを設定します。たとえば、 
    echo "ServerAliveInterval 600" >> ~/.ssh/config
    ...またはエディタを使用してください。

サービス端末

  1. にあるsshd設定ファイルを開きます/etc/ssh/sshd_config。
  2. パラメータClientAliveIntervalとClientAliveCountMaxを希望の値に設定します。

たとえば、およびは、ClientAliveInterval=200サーバーClientAliveCountMax=3が200秒後にアクティビティメッセージを送信することを意味します。クライアントが応答しない場合は、400秒後に別のアクティビティメッセージを送信します。クライアントがまだ応答しない場合は、600秒後に別の接続維持メッセージを送信します。それでも応答がない場合、SSH接続は切断されます。

源泉：SSH接続の壊れたパイプエラーの修正 存在する Linux マニュアル。

答え3

Mac で Windows ノートブックで SSH を試行中にこの問題が発生しました。上記の回避策をServerAliveInterval試しましたが、うまくTCPKeepAliveいきませんでした。

なぜこれが起こったのかはわかりませんが、リモートノートブックファイルから公開SSHキーを削除して~/.ssh/authorized_keys問題を解決しました。しかし、これは特に奇妙です。私のssh -vログによれば、私の公開鍵は認証に正しく使用されているようです。

debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.21 ([192.168.1.21]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: filesystem full
client_loop: send disconnect: Broken pipe

とにかく、キーを削除するとエラーがなくなり、client_loop: send disconnect: Broken pipeログインできます。

答え4

この問題は、サブシステムを使用している場合に解決される可能性があります。その後、これらの所有者は他の所有者ではなくルートである必要があり、権限を制限する必要があります。

私もこの問題に直面しました

Client_loop: send disconnect: broken pipe

問題を作成した他のすべてのユーザーにすべての権限を付与したためです。

私を見て/var/log/auth.logバグを見つけた後、問題を作成したすべてのユーザーにすべての権限を与えました。

権限を変更した後、接続に成功しました。より少ない権限が必要なので、これは素晴らしいです。

sudo chown root:root /rooted/Environment 
sudo chmod 755 /rooted/Environment

関連情報