web-dev-qa-db-ja.com

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
macosssh
9
Dylan

これが、SSHサーバーに接続する際の「ssh_exchange_identification：接続がリモートホストによって閉じられました」エラーを解決する方法です。

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

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

chetic@ubuntu:~$ ssh -v [email protected]
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を起動したところ、問題はありませんでした。私の場合、問題は、最初にルートに解凍したパッケージのバージョンが正しくないことが原因でした。

4
Chetic

同じエラーが発生していました（ただし、ssh localhostを介した問題のあるマシンを含め、どのマシンからでも）。

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

とにかく、/ var/empty所有者がユーザー名に変更された理由は完全にわかりませんが、sshは必ず/var/emptyをrootが所有する必要があります（そうでない場合はssh_exchange_identification: read: Connection reset by peerを取得します）：

    Sudo chown root /var/empty
3
hunter3740

これはローカルマシンの問題ではなく、サーバー側の問題です。 複数の要因 がこの問題を引き起こしている可能性があります：

  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に設定されているときにハンドシェイクが発生する方法です。

1
Karthik Rangarajan

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

1
anonymous

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

Sudo chmod 660 File_Name

0
Srijan Chaudhary

この問題を自分で簡単に解決できました。

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

ただし、（私の場合のように）ヘッドレスサーバーの場合は、OSXサーバーアプリを使用して（サーバー名）/設定に移動し、「Secure Shell接続のオンとオフを再度切り替える」ことができます。

0
Sirens