
私は約 1 か月間、Mac 経由でリモート サーバーに接続しています。しかし最近、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
いくつか調査した後、次のことを試しました...
- ルーターを再起動しました
- 「known_hosts」ファイルをクリアしました
- 「known_hosts」ファイルを削除しました
- DHCPをリリースして更新しました
- 別のデバイス(Windows)からPuttyを使用して試してみましたが、エラーが発生していました
この通信を阻止するためにサーバーに変更を加えていないことに注意してください。
また、これが問題を引き起こすかどうかはわかりませんが、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
答え1
これは、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
Google で検索すると、hosts.deny と hosts.allow を確認するように勧められるだけでしたが、私のターゲット マシンにはそのようなファイルはありませんでした。
再起動後 (Karthik の提案に従って) sshd は実行されませんでした。ターゲットで sshd を手動で起動してみました:
# sshd
OpenSSL version mismatch. Built against 1000002f, you have 1000105f
/usr/lib/libssl.a を元のバージョンに置き換えて sshd を起動すると、正常に戻りました。私の場合、問題は、最初にルートに解凍したパッケージのバージョンが間違っていたために発生しました。
答え2
私も同じエラーを経験していました (ただし、 経由の問題のあるマシンを含むすべてのマシンからssh localhost
)。
これは、ユーザープロファイルを移行したときに発生しました。つまり、ルートとしてファイルをコピーした後、次のようなコマンドを実行しました。chown -R username /Users/username/Destop
とにかく、/var/empty の所有者がユーザー名に変更された理由がまったくわかりませんが、間違いなくroot が所有するssh
必要があります(そうでない場合は、次のようになります)。/var/empty
ssh_exchange_identification: read: Connection reset by peer
sudo chown root /var/empty
答え3
これはローカルマシンの問題ではなく、サーバー側の問題です。複数の要因この問題の原因:
- リモート サーバー上の /etc/hosts.allow または /etc/hosts.deny 構成の変更。
- サーバーの負荷が重いです。
過去にこのような問題が発生したとき、私は次の 2 つのうちのいずれかを次の順序で実行しました。
- 上記の記事を参考にして /etc/hosts.allow を変更します。(SSH サーバーを再起動します)
- /etc/hosts.allow がすでに必要な状態になっている場合は、SSH サーバーを再起動するだけです (この操作を行うときは注意してください)。
- 再起動しても問題が解決しない場合は、サーバー キーを再生成して SSH サーバーを再起動します (このマシンにログインするすべてのユーザーに、サーバーのキーが変更されたというエラーが表示されるため、これは危険です)
多くの場合、1で問題は解決しますが、場合によっては2を実行する必要があります。なぜそれは事実です。うまくいっただけです。キーの提示方法に関係しているのかもしれませんし、何らかの理由で破損したのかもしれません。よくわかりません。しかし、私が知っているのは、このエラーは完全にサーバーと関係があり、SSH 接続が設定されているときにハンドシェイクが行われる方法に関係しているということです。
答え4
これは確かにバグです。ssh は私のマシンの 1 つでは動作しますが、他のマシンでは動作しません。私はこれを解決しました。次の手順に従ってください。
- 有効期限のないアクセス トークンを生成し、利用可能なすべてのオプションを選択します。
- 既存の SSH キーを削除します。
- ssh ではなく https を使用してリポジトリをクローンします。
- ユーザー名を使用しますが、パスワードの代わりに生成されたアクセス トークンを使用します。
あるいは、既存のリポジトリでこのコマンドを使用してリモートをhttpに設定し、このコマンドgit remote set-url originを使用することもできます。https://gitlab.com/[ユーザー名]/[リポジトリ名].git