SSH接続：ssh_exchange_identifcation

Macを使って約1か月間、リモートサーバーに接続しています。最近のことですが、ssh dylan @ MY_IPを使用して接続しようとしたところ、このメッセージが表示されました。

ssh_exchange_identification: read: Connection reset by peer

診断情報も取得しました...

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to {MY IP{ [MY IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/id_rsa type -1
debug1: identity file /Users/watson/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/watson/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /Users/watson/.ssh/id_dsa type 2
debug1: identity file /Users/watson/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

いくつかの調査を行った後、私は次のことを試しました...

1. ルーターを再起動しました
2. 「known_hosts」ファイルをクリアした
3. 「known_hosts」ファイルを削除しました
4. DHCPをリリースおよび更新しました
5. エラーが発生したPuttyを使用して別のデバイス（Windows）からも試しました

この通信を禁止するためにサーバーに変更を加えていないことに注意してください。

また、これが問題を引き起こすかどうかはわかりませんが、ドメイン名とIPで接続しています。

また、別のIPアドレスからの接続にも成功しました。

これは多くのリソースが存在する大きな問題であることはわかっていますが、多くの解決策が機能せず、誰にとってもどのような種類の解決策も実際にはわかりませんでした。

更新

プロトコル1に強制しました。「ピアによる接続のリセット」の代わりに、「リモートホストによって接続がクローズされました」が表示されます。デバッグ情報を明らかにして実行：

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 *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MY_IP [MY_IP] port 22.
debug1: Connection established.
debug1: identity file /Users/watson/.ssh/identity type -1
debug1: identity file /Users/watson/.ssh/identity-cert type -1
ssh_exchange_identification: Connection closed by remote host

これが、SSHサーバーに接続するときの「ssh_exchange_identification：リモートホストによる接続のクローズ」エラーを解決する方法です。

パッケージをルートに解凍した後、組み込みLinuxマシンに接続しようとすると、このエラーが発生しました。libsslを含む多くのライブラリファイルが置き換えられました。

接続しようとしています：

chetic@ubuntu:~$ ssh -v root@192.168.1.100
OpenSSH_6.2p2 Ubuntu-6ubuntu0.3, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to SC [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/delaval/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/delaval/.ssh/id_rsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_dsa type -1
debug1: identity file /home/delaval/.ssh/id_dsa-cert type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa type -1
debug1: identity file /home/delaval/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.3
ssh_exchange_identification: read: Connection reset by peer

グーグルは、hosts.denyとhosts.allowをチェックすることを提案しているように見えましたが、私のターゲットマシンにはそのようなファイルがありませんでした。

再起動後（Karthikの提案に従って）sshdが実行されていませんでした。ターゲットで手動でsshdを起動してみました：

# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f

/usr/lib/libssl.aを元のバージョンに置き換えてsshdを起動したところ、問題はありませんでした。私の場合、問題は、最初にルートに解凍したパッケージのバージョンが正しくないことが原因でした。

同じエラーが発生しました（ただし、問題のあるマシンを含むすべてのマシンからssh localhost）。

ユーザープロファイルを移行したときに開始されました。つまり、ルートとしてファイルをコピーした後、次のようなコマンドを実行しましたchown -R username /Users/username/Destop

とにかく、なぜ/ var / empty所有者がユーザー名に変更されたのかは完全にわかりsshませんが、間違いなく/var/emptyrootが所有している必要があります（それ以外の場合はssh_exchange_identification: read: Connection reset by peer）：

    sudo chown root /var/empty

これはローカルマシンの問題ではなく、サーバー側の問題です。この問題の原因は複数あります。

1. リモートサーバーの/etc/hosts.allowまたは/etc/hosts.deny構成の変更。
2. サーバーの負荷が高い。

過去にこれらの問題が発生した場合、次の順序で2つのことのいずれかを実行しました。

1. 上記の記事で参照されている/etc/hosts.allowを変更します。（SSHサーバーを再起動します）
2. /etc/hosts.allowがすでに必要な方法である場合は、SSHサーバーを再起動するだけです（これを行うときは注意してください！）
3. 再起動が機能しない場合は、サーバーキーを再生成してSSHサーバーを再起動します（このマシンにログインするすべてのユーザーが、キーが変更されたサーバーに関するエラーを受け取るため、これは危険です）

たいていの場合、1で問題が解決しますが、場合によっては2を実行する必要がありました。なぜそうなるのか理解できず、うまくいっただけです。おそらく、キーの提示方法に何らかの問題があるか、何らかの方法でキーが破損している可能性があります。しかし、私が知っていることは、エラーは完全にサーバーと関係があり、SSH接続がuoに設定されているときにハンドシェイクが発生する方法です。

CygwinでSSHをセットアップしましたが、私の場合、まさにこのエラーを引き起こしたのはWindowsファイアウォールだったので、ポート22への接続を許可してください。

私はこの問題を本当に簡単に解決することができました。

通常のOS Xでは、システム環境設定/共有で「リモートログイン」を切り替えるだけでこれを解決できます。

ただし、（私の場合のように）ヘッドレスサーバーの場合は、OSXサーバーアプリを使用して（サーバー名）/設定に移動し、[Secure Shell connections on and off]を切り替えることができます。

プライベートキーまたはセキュリティキーを使用してサーバーにログインしている場合は、コマンドを使用して、キーファイルの権限を660に変更する必要があります。

sudo chmod 660 File_Name