ssh_exchange_identification：読み取り：ピアによる接続のリセット

私はOS Xでubuntu 12.04サーバーにsshしようとしています。突然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

これまでのところ（掲示板のアドバイスで）ホスト拒否ファイルを探しましたが、私のマシンにはそのようなファイルはありません。

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

クライアントマシンで管理者アクセス権を持っていますが、サーバーではありません。

突然の変更は、サーバーsshd構成の構成ファイルの変更の結果である可能性がありますが、管理者権限がないと確認または変更できないことを示します。サーバーの管理者に（時間内に）アクセスできない場合は、引き続き次のことを試すことができます。

ログはローカルバージョン文字列のみを示しsshdます。サーバーと中間マシンで実行されているバージョンを確認する必要があります。

これらのバージョンが異なる場合（特にローカルマシンとサーバー間、および中間マシンとサーバー間が少ない場合）、ネゴシエーションの非互換性がある可能性があります。これは以前に発生しましたssh。解決策は、コマンドライン（ssh -c aes256-ctrなど）またはのいずれかでCiphers、HostKeyAlgorithmsおよび/またはMACエントリを短縮すること/etc/ssh/ssh_configでした。

-c/ Ciphers、-o HostKeyAlgorithms/ HostKeyAlgorithmsおよび-m/ MACsコマンドラインの各引数の適切な値については、デバッグ情報を（中間経由でサーバーに接続して）調べる必要があります。ssh_configの変更。

私はしばらくこの問題を抱えていませんでしたが、IIRCを実行したときにCiphersとHostKeyAlgorithmsの設定を手動で強制するのに十分でした。その後、サーバーのsshdバージョンを更新でき、問題はなくなりました。

fail2banまたはによって禁止された可能性がありますdenyhosts。このような場合（また、確認するため）、サーバープロバイダーの支援に煩わされたくない場合は、別のIPアドレスからサーバーにログインする必要があります。たとえば、別のサーバー、友人のホーム接続、またはwifiホットスポット、またはTORでSSHを使用します。

ログインしたら、IPアドレスが/etc/hosts.deny（サーバー側で）実際に表示されることを確認します。もしそうなら、fail2banあるいはdenyhosts実際に犯人でなければなりません。

denyhosts住所を継続的にブロックしないようにする手順については、この質問への回答を参照してください。以下のためfail2banにあなたのIPアドレスを見つけiptables -L --line-number、あなたが使用してIP禁止を解除iptables -D <chain> <chain number>、あなたは上の詳細をチェック向けHowtoForgeを。

あなたのIPアドレスがに追加することもできますfail2banし、denyhosts（それぞれホワイトリスト/etc/fail2ban/jail.conf、ラインignoreip、そして/var/lib/denyhosts/allowed-hosts再び発生する問題を防ぐために）、必要であれば、それを作成する（ただし、パスがあなたのディストリビューションに異なる場合があることに注意してください）。

ホストサーバーで、~/.ssh/authorized_keysmacのssh pub.keyを削除します。次にtail -f /var/log/auth.log、別のターミナルを開いて、sshを再試行しますssh -v me@server。パスワードの入力を求められた場合は、sshキーに問題がありました。「ssh_exchange_identification：read：Connection reset by peer」応答がまだ表示されている場合は、失敗した後に「/var/log/auth.log」ファイルのログエントリから問題を特定できるはずです。ログインします。

それでも接続に失敗する場合は、認証ファイルからログに記録されたエントリをここに投稿してください。回答を修正します。

これは、ネットワーク上に同じMACアドレスを持つ複数のマシンがある場合に発生する可能性があります（たとえば、仮想マシンのコピーを作成してMACの変更を忘れた場合）。

ISPのネームサーバーが原因で、これを取得していました/etc/resolv.conf。これらのネームサーバーはしばしば過負荷になり、逆DNSルックアップが失敗sshdすると接続が切断されます。より信頼性の高いネームサーバー、たとえばを使用して問題を解決しました8.8.8.8。

私は同じ問題に直面しました。sshセッションは正常に開きましたが、しばらくするとリセットされます。すぐにゲインを接続しようとすると、「接続が拒否されました」というエラーが表示されます。セッションをデバッグすると、接続がリセットされたときにこのメッセージが表示されました

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com 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でログを見つけることができるはずです。

クライアントがバージョン番号を送信した直後に接続が切断されたため、サーバーが何らかの形でクライアントを互換性がないと脅していると推測できます。

私は同じ問題を抱えていたが、原因は異なることが判明した。間違ったポートを使用していた。

ssh指定されたエラーの新しいバージョンではConnection refusedまたはBad portです。

古いバージョンでは、与えられたエラーは ssh_exchange_identification: read: Connection reset by peer

したがって、このようなエラーが発生した場合は、ポートが正しいかどうかを確認してください。

私はこの質問が古いことを知っていますが、私が見つけたいくつかの発見を共有したかったです。/var/empty/sshdサーバー上に適切な所有権と許可があるかどうかを確認してください。

一部のディレクトリパーミッションを更新するように修正されたchefスクリプトがありましたが、意図したターゲットの下のディレクトリを誤って更新し、/ varの所有権をアプリケーションユーザー/グループに変更し、パーミッションを775に変更しました。

Answerで明示的に言及されていないため、このエラーが表示される別の方法は、ユーザーとサーバー間のネットワークベースのファイアウォールが接続をブロックすることを決定した場合です。ファイアウォールは、OS XシステムのIPからの「多すぎる」接続があると判断し、それをブロックし始めた可能性があります。他のシステムからの「多すぎる」接続はまだなかったため、許可されました。

サーバーから最後に受信したメッセージは、認証の試行を開始する前に発生するメッセージです。これは、アカウント、キー、またはパスワードに関する大きな可能性を排除します。

ベンダーのランダムサンプリングによるこのようなブルー​​トフォースポリシーの例は次のとおりです。

• CloudFlare：レート制限を使用してブルートフォース攻撃から保護するにはどうすればよいですか？
• F5：ブルートフォース攻撃保護の設定
• FortiNet：カスタムIPSシグネチャを作成してパターンレートを検出-ブルートフォース攻撃を検出する例
• パロアルト：ブルートフォース攻撃を防ぐ
• Sonicwall：SRAでブルートフォースおよび辞書攻撃をブロックする方法