ssh_exchange_identification：読み取り：ピアによって接続がリセットされました
私はOS XでUbuntu 12.04サーバーにSSH接続しようとしています。私はSSHで接続できました-突然何かが機能しなくなるまで。これをデバッグするために-vを使用するためにオンラインで読みました。出力を以下に示します。別のボックスにSSHでログインし、そのボックスからサーバーにSSHでログインすると、ログインできます。この問題をデバッグする方法はわかりませんが、学びたいです。
$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer
これまでのところ（メッセージボードのアドバイスで） hosts deny ファイルを探しましたが、私のマシンにはそのようなファイルはありません。
$ cat /etc/hosts.deny
cat: /etc/hosts.deny: No such file or directory
クライアントマシンには管理アクセス権がありますが、サーバーにはアクセスできません。
突然の変更は、サーバーの構成ファイルsshd構成の変更の結果である可能性がありますが、管理者権限がないとそれを確認または変更できないことを示します。サーバーの管理者に（時間内に）到達できない場合でも、以下を試すことができます。
ログにはローカルバージョン文字列のみが示されます。サーバーと中間マシンで実行されているsshdのバージョンを確認する必要があります。
これらのバージョンが異なる場合（特にローカルマシンとサーバー間で異なり、中間マシンとサーバー間でそれより少ない場合）、ネゴシエーションの非互換性がある可能性があります。これは、sshの= 以前に発生した です。以前は、コマンドライン（ssh -c aes256-ctrなど）または/etc/ssh/ssh_configのいずれかで、Ciphers、HostKeyAlgorithms、MACエントリを短くするためのソリューションでした。
-c/Ciphers、-o HostKeyAlgorithms/HostKeyAlgorithmsの引数として適切な値を（中間体を介してサーバーに接続して）デバッグ情報を調べる必要があります。 -m/MACsコマンドラインレスポンス。 ssh_configの変更。
私自身、しばらくこの問題を抱えていませんでしたが、IIRCを実行すると、CiphersとHostKeyAlgorithmsの設定を手動で強制するのに十分でした。その後、サーバーのsshdバージョンを更新して問題を解消しました。
fail2banまたはdenyhostsによって禁止されている可能性があります。このような場合（およびそれをチェックするため）、サーバープロバイダーの支援を必要としない場合は、別のIPアドレスからサーバーにログインする必要があります。別のサーバー、または友人の家の接続、またはwifiホットスポット、またはSSHとTORの使用。
ログインしたら、IPアドレスが実際に/etc/hosts.deny（サーバー側）に表示されることを確認します。その場合は、fail2banまたはdenyhostsが実際に原因である必要があります。
denyhostsがアドレスを継続的にブロックしないようにする手順については、 この質問の回答を参照してください。 fail2banでiptables -L --line-numberを使用してIPを検索し、iptables -D <chain> <chain number>でIPの禁止を解除するには、詳細を howtoforge で確認します。
IPアドレスをfail2banおよびdenyhostsホワイトリストに追加することができます（それぞれ/etc/fail2ban/jail.conf、行ignoreip、および/var/lib/denyhosts/allowed-hosts）。必要に応じて作成します（ただし、パスがディストリビューションによって異なる場合があることに注意してください））。問題が再発しないようにしてください。
ホストサーバーで、次の場所にあるssh pub.keyを削除します：~/.ssh/authorized_keysfor Mac。次にtail -f /var/log/auth.log別のターミナルを開いて再度sshを実行する間ssh -v me@server。パスワードの入力を求められた場合は、sshキーに問題があります。 「ssh_exchange_identification：read：Connection reset by peer」という応答が引き続き表示される場合は、試行が失敗した後、「/ var/log/auth.log」ファイルのログエントリから問題を特定できます。ログインします。
それでも接続に失敗する場合は、authファイルからログに記録されたエントリをここに投稿してください。回答を修正します。
これは、ネットワーク上に同じMACアドレスを持つ複数のマシンがある場合に発生する可能性があります（たとえば、仮想マシンのコピーを作成し、MACを変更し忘れた場合）。
私も同じ問題に直面しました。 sshセッションは正常に開きますが、しばらくするとリセットされます。すぐにゲインを接続しようとすると、「接続が拒否されました」というエラーが表示されます。セッションをデバッグすると、接続がリセットされたときにこのメッセージが表示されました
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote Host 10.x.y.z: Connection reset by peer
Connection to 10.x.y.z closed.
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
debug1: Exit status -1
この時点で、ネットワーク上でIPアドレスの競合が発生していることに気付きました。別の住所に変更して問題は解決しました
ログは、サーバー側が接続をドロップすることを意味します。理由を調べるには、サーバー側のログを調べ、切断の理由を示す必要があります。/var/log/messagesでほとんど常にログを見つけることができるはずです
クライアントがバージョン番号を送信した直後に接続が切断されたため、サーバーがなんらかの理由でクライアントを互換性がないと脅迫していると思います。
ISPのネームサーバーが/etc/resolv.conf。これらのネームサーバーはしばしば過負荷になり、逆DNSルックアップが失敗した場合、sshdは接続をドロップします。私は、より信頼性の高いネームサーバーを使用して問題を解決しました。 8.8.8.8。
私は同じ問題を抱えていましたが、原因が異なることがわかりました。間違ったポートを使用していたのです。
新しいバージョンのsshでは、エラーはConnection refusedまたはBad port。
古いバージョンでは、与えられたエラーはssh_exchange_identification: read: Connection reset by peer
したがって、このようなエラーが発生した場合は、ポートが正しいかどうかを確認してください。
Answerで明示的に言及されていないため、このエラーが表示されるもう1つの方法は、ユーザーとサーバー間のネットワークベースのファイアウォールが接続をブロックすることを決定した場合です。ファイアウォールは、OS XシステムのIPからの「多すぎる」接続があると判断し、それをブロックし始めた可能性があります。他のシステムからの「多すぎる」接続はまだないため、許可されました。
サーバーから受信した最後のメッセージは、認証の試行を開始する前に発生するメッセージであり、アカウント、キー、またはパスワードを取り巻く可能性の大きなクラスを除外します。
ベンダーの無作為抽出によるそのようなブルートフォースポリシーの例は次のとおりです。
私はこの質問が古いことを知っていますが、私が得たいくつかの発見を共有したいと思います。 /var/empty/sshdサーバー上の適切な所有権とアクセス許可があります。
一部のディレクトリ権限を更新するように変更されたchefスクリプトがありましたが、意図したターゲットの下のディレクトリを誤って更新し、/ varの所有権をアプリケーションユーザー/グループに変更し、権限を775に変更しました。
Androidデバイス（Huawei P30 Pro）のWi-Fiブリッジオプションを介してリモートホストallに接続しようとすると、この正確なエラーが発生しました。 USBテザリングオプションを使用して同じインターネット接続を共有しても問題ありません。
クライアントやサーバーのSSH設定やオプションは、他に何も変更されていません。
TL; DR：時々、何もできません。