web-dev-qa-db-ja.com

ssh_exchange_identification：リモートホストによって接続が閉じられました

Ubuntu 10.10をリモートボックスで実行しています。私は毎日問題なくsshしていますが、今日は突然、次のエラーが発生します。

ssh_exchange_identification: Connection closed by remote Host

-vvで接続すると、次のようになります。

OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/bla/.ssh/config
debug1: Applying options for ubuntu-server
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to ubuntu-server.com [123.123.123.123] port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /Users/bla/.ssh/id_rsa type -1
debug1: identity file /Users/bla/.ssh/id_rsa-cert type -1
ssh_exchange_identification: Connection closed by remote Host

キーを削除すると、まったく同じ出力が得られます（sans "debug2：key_type _...）。物理的にログインしてhosts.allowとhosts.denyを確認できましたが、エントリがありません。OpenSSHを削除して再インストールし、authorized_keysと~/.sshのアクセス許可を確認して、同じエラーが発生するように他のコンピューターから接続しようとしました。問題は解決しました。

ubuntussh
14
Carlos

同じエラー

ssh_exchange_identification：リモートホストによって閉じられた接続

秘密鍵（ファイル）がすべてのユーザーによって読み取り可能である場合、つまり、誤ったアクセス許可を持っている場合に発生します。

たとえば、秘密鍵のいずれか

  • ssh_Host_key
  • ssh_Host_dsa_key
  • ssh_Host_rsa_key

/etc/ssh/はchmod 644です（chmod 600である必要があります）。

次の権限により、「ssh_exchange_identification：リモートホストによって接続が閉じられました」エラーが発生します。

root@Host:/etc/config/ssh# ls -la
drwxrwxrwx    2 root     root            0 Aug 24  2005 .
drw-rw-rw-    3 root     root            0 Apr  3  2007 ..
-rw-r--r--    1 root     root        88039 Aug 24  2005 moduli
-rw-r--r--    1 root     root         1559 Aug 24  2005 ssh_config
-rw-r--r--    1 root     root          668 Aug 24  2005 ssh_Host_dsa_key
-rw-r--r--    1 root     root          599 Aug 24  2005 ssh_Host_dsa_key.pub
-rw-r--r--    1 root     root          524 Aug 24  2005 ssh_Host_key
-rw-r--r--    1 root     root          328 Aug 24  2005 ssh_Host_key.pub
-rw-r--r--    1 root     root          883 Aug 24  2005 ssh_Host_rsa_key
-rw-r--r--    1 root     root          219 Aug 24  2005 ssh_Host_rsa_key.pub
-rw-r--r--    1 root     root         2018 Aug 25  2005 sshd_config

権限が修正され、接続が受け入れられるようになりました。

root@Host:/etc/config/ssh# ls -la                    
drwxrwxrwx    2 root     root            0 Aug 24  2005 .
drw-rw-rw-    3 root     root            0 Apr  3  2007 ..
-rw-r--r--    1 root     root        88039 Aug 24  2005 moduli
-rw-r--r--    1 root     root         1559 Aug 24  2005 ssh_config
-rw-------    1 root     root          668 Aug 24  2005 ssh_Host_dsa_key
-rw-r--r--    1 root     root          599 Aug 24  2005 ssh_Host_dsa_key.pub
-rw-------    1 root     root          524 Aug 24  2005 ssh_Host_key
-rw-r--r--    1 root     root          328 Aug 24  2005 ssh_Host_key.pub
-rw-------    1 root     root          883 Aug 24  2005 ssh_Host_rsa_key
-rw-r--r--    1 root     root          219 Aug 24  2005 ssh_Host_rsa_key.pub
-rw-r--r--    1 root     root         2018 Aug 25  2005 sshd_config
3
Kasreyn

ほぼ間違いなく/etc/hosts.denyファイルにはマシンのエントリがあります。追加してください

sshd: xxx.yyy.zzz.aaa

/etc/hosts.allowへの接続IPアドレス

2
Tom H

CentOS7の私にとっては、sshdのデフォルト設定であるMaxStartupsと相まって、ブルートフォースログインが何度も試行されたことが原因でした。

sshd_config のマニュアルページには次のように書かれています：

MaxStartups

SSHデーモンへの認証されていない同時接続の最大数を指定します。認証が成功するか、接続のLoginGraceTimeが期限切れになるまで、追加の接続はドロップされます。デフォルトは10です。

または、3つのコロンで区切られた値 '' start：rate：full ''（たとえば、 "10:30:60"）を指定して、ランダムな早期ドロップを有効にすることができます。 sshd（8）は、現在 '' start ''（10）の認証されていない接続がある場合、 '' rate/100 ''（30％）の確率で接続試行を拒否します。確率は直線的に増加し、認証されていない接続の数が「フル」（60）に達すると、すべての接続試行が拒否されます。

開始値を25に設定します（例：MaxStartups 25:30:100）/etc/ssh/sshd_configが問題を解決しました。

1
kalebo
-rw------- 1 user group 405 2011-10-29 10:20 authorized_keys2

authorized_keys2 is deprecated from version 3.0。

debug3: Not a RSA1 key file /Users/bla/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace

秘密鍵が破損しているようです。鍵ペアを再生成し、ssh-copy-idを使用して公開鍵をauthorized_keysファイルにインストールし、再試行してください。

1
quanta

何かをする間に新しいファイアウォールがあるかもしれません。私はかつて、導入された新しいファイアウォールでまったく同じ問題が発生するという問題に直面しました。新しいファイアウォールがサーバー側に導入されました。

1
proy

ここでいくつかの問題が発生する可能性があります。

  1. 受け入れられる認証のタイプを制限するようにサーバーが構成されていますか？これは、*Authenticationファイルのさまざまなsshd_configディレクティブで設定できます。
    • 認証にPAMを使用している場合は、その構成を確認してください
  2. 鍵が他の形式になっているようです。 ssh-keygen-e-iフラグと-mフラグを確認してください。
0
akraut