web-dev-qa-db-ja.com

SSHエラーssh_exchange_identification：読み取り：接続がピアによってリセットされました

サーバーにsshにアクセスしようとしていますが、 "ssh_exchange_identification：read：Connection reset by peer"を取得しました。コンピューターを自宅に移動すると同じクライアントが正常に動作しますが、コンピューターがオフィスにあるときにエラーが表示されます。オフィスネットワークのLANネットワーク設定で問題が発生する可能性はありますか？同じ問題で、オフィスネットワーク内の他のコンピューターを試しました。

この問題を修正するためにサーバー設定を変更できますか？

同じDebianを使用するクライアントとサーバー "Linux debian 3.16.0-4-AMD64＃1 SMP Debian 3.16.7-2（2014-11-06）x86_64 GNU/Linux"

クライアント側では、ログは次を示します：

OpenSSH_6.7p1 Debian-3、OpenSSL 1.0.1j 2014年10月15日
 debug1：設定データの読み取り/home/client/.ssh/config
debug1：/home/client/.ssh/config行13：navtk 
 debug1のオプションの適用：構成データの読み取り/etc/ssh/ssh_config
debug1：/ etc/ssh/ssh_config行19：* 
 debug1：のオプションの適用：ホスト名変更されました;構成の再読み取り
デバッグ1：構成データの読み取り/home/client/.ssh/config
デバッグ1：構成データの読み取り/etc/ssh/ssh_config
デバッグ1：/ etc/ssh/ssh_config行19：* 
 debug2のオプションの適用：ssh_connect：needpriv 0 
 debug1：www.Host.com [xx.xx.xx.xx]ポートxx。[.____。への接続] debug1：接続が確立されました。
 debug1：IDファイル/home/client/.ssh/user type 1 
 debug1：key_load_public：No such file or directory 
 debug1：identity file/home/client/.ssh/user-cert type -1 
 debug1：プロトコル2.0の互換モードを有効にする
 debug1：ローカルバージョン文字列SSH-2.0-OpenSSH_6.7p1 Debian-3 
 ssh_exchange_identification：読み取り：接続がピアによってリセットされました

そしてサーバー側のログイン

::ポート443でリッスンしているサーバー。
 debug3：fd 5はO_NONBLOCKではありません
 debug1：デバッグモードで実行している場合、サーバーはforkしません。 config len 735 
 debug3：ssh_msg_send：type 0 
 debug3：send_rexec_state：done 
 debug1：rexec start in 5 out 5 newsock 5 pipe -1 sock 8 
 debug1 ：削除後のinetdソケット：3、3 
 debug1：getpeername failed：Transport endpoint is not connected 
 debug1：get_remote_port failed
linuxnetworkingsshdebianvpn
6
Tmx

「ピアによる接続のリセット」とは、TCPストリームが反対側から異常に閉じられたことを意味します。最も可能性の高い説明は、接続を処理するリモートサーバープロセスがクラッシュしたか、ネットワークデバイス（ステートフルファイアウォールまたはロードバランサーのように）接続を妨害することにしました。

可能であれば、リモートサーバーでこれをデバッグする必要があります。 sshdはsyslogを介してログを記録します。一般的なUnixシステムでは、ログエントリは/var/logディレクトリ内のファイルの1つにあります。運がよければ、sshdはセッションを切断するたびに何かをログに記録します。

サーバーでrootアクセス権がある場合、sshdのデバッグインスタンスを実行できます。 rootになって実行します。

/path/to/sshd -ddd -p 1022

これにより、SSHサーバーのインスタンスが実行され、ポート1022で待機し、1つの接続を受け入れ、デバッグ情報を端末に出力します。ポートとしてポート1022を指定することを除いて、通常どおりクライアントを実行します。

ssh -p 1022 user@Host

サーバーによって出力されたデバッグ情報は、何が起こっているのかを明確にするのに役立ちます。

編集：サーバー出力は、サーバーがクラッシュしていないか、TCP接続を意図的に閉じていないことを示しています。何かが原因でサーバーが閉じています。サーバーにインストールされているセキュリティソフトウェアを確認しますTCPセッション、およびファイアウォール、ロードバランサー、またはローカルネットワークの一部である可能性のある同様のネットワークハードウェアを監視する可能性があります。

4
Kenster

同じ問題が発生しています。現在、問題は私のISPにあるようです。サーバーにtracerouteを実行してみてください。私にとって、これはサーバーに到達する前に失敗します。

私のサーバーは共有ホスティングサーバーです。私のホスティング会社から、AT＆TまたはComcastを使用している他のクライアントでも同じ問題が発生しているとのことでした。

これが役立つこと、または少なくとも他の可能性に過度の時間を費やすことからあなたが救われることを願っています。

1
Roger Creasy

ここでは手遅れですが、これに飛び込むだけの人かもしれません。

  1. サーバーを再始動（停止および開始）します。
  2. パブリックIPを使用したsshによるサーバーへのアクセス。 （成功した場合は、次のステップに進むことができます。）
  3. Webサーバーを再起動します。

それだけです、またはドメインをパブリックIPに再度ポイントする必要があるかもしれません。

私の環境はAWSとNGINXです。

1
Pirun Seng

多くの理由が考えられますが、最も可能性の高い理由の1つは、（私の場合はそうでした）ssh /ポート22はファイアウォールによって許可されていませんです。

ser-interfaceでssh接続を許可できます（一部のプロバイダーはそれを許可します）またはログインする別の方法がある場合（例：digitaloceanはコンソールボタンを提供します）以下のコマンドを実行できます

Sudo ufw allow ssh
Sudo ufw allow 22
0
BSB

「ssh_exchange_identification：read：Connection reset by peer」は、ブロックリストに登録された場合にも発生します（たとえば、間違ったパスワードを頻繁に入力したため）。私のSynology-NASで私に起こった。したがって、接続元のIPがそのリストにないことを確認してください。

Synologyの場合は、「コントロールパネル」/「セキュリティ」/「アカウント」で確認してください。

0
kalmiya

これは遅すぎるかもしれませんが、いつか誰かの日を救うことができます。まあ、同じ問題がありましたssh:my.ip.address の中に /etc/hosts.allowファイルし、サーバーを再起動しました。

Ps：これは、他の方法でサーバーにアクセスできる場合に機能します。

0
Okello