web-dev-qa-db-ja.com

SSH:DH_GEXグループが範囲外です

最近、OpenSSHにベンダー提供のパッチを適用しました。このパッチは、最近のLogjam攻撃に対応して、いくつかのキー交換プロトコルを無効にしました。このパッチを適用した後、接続のネゴシエーションが失敗したため(おそらく非推奨のキー交換アルゴリズムが原因で)、sftp経由でファイルを交換できなかったベンダーがいくつかあります。

ベンダーと話す前に、私たちが目にしていることをいくつか確認したいと思います。問題のあるベンダーの1つとのSSHセッションの例を次に示します(行番号が追加されています)。

# ssh -vv [email protected]
01 OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009
02 debug1: Reading configuration data /etc/ssh/ssh_config
03 debug1: /etc/ssh/ssh_config line 20: Applying options for *
04 debug2: ssh_connect: needpriv 0
05 debug1: Connecting to Host.domain.com [1.2.3.4] port 22.
06 debug1: Connection established.
07 debug1: permanently_set_uid: 0/0
08 debug1: identity file /root/.ssh/id_rsa type -1
09 debug1: identity file /root/.ssh/id_rsa-cert type -1
10 debug1: identity file /root/.ssh/id_dsa type -1
11 debug1: identity file /root/.ssh/id_dsa-cert type -1
12 debug1: identity file /root/.ssh/id_ecdsa type -1
13 debug1: identity file /root/.ssh/id_ecdsa-cert type -1
14 debug1: Enabling compatibility mode for protocol 2.0
15 debug1: Local version string SSH-2.0-OpenSSH_6.2
16 debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
17 debug1: no match: GXSSSHD_Comments
18 debug2: fd 3 setting O_NONBLOCK
19 debug1: SSH2_MSG_KEXINIT sent
20 debug1: SSH2_MSG_KEXINIT received
21 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
22 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
23 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
24 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
25 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,[email protected],zlib
28 debug2: kex_parse_kexinit: none,[email protected],zlib
29 debug2: kex_parse_kexinit:
30 debug2: kex_parse_kexinit:
31 debug2: kex_parse_kexinit: first_kex_follows 0
32 debug2: kex_parse_kexinit: reserved 0
33 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
34 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
35 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
36 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
37 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
39 debug2: kex_parse_kexinit: none,zlib
40 debug2: kex_parse_kexinit: none,zlib
41 debug2: kex_parse_kexinit:
42 debug2: kex_parse_kexinit:
43 debug2: kex_parse_kexinit: first_kex_follows 0
44 debug2: kex_parse_kexinit: reserved 0
45 debug2: mac_setup: found hmac-md5
46 debug1: kex: server->client aes128-ctr hmac-md5 none
47 debug2: mac_setup: found hmac-md5
48 debug1: kex: client->server aes128-ctr hmac-md5 none
49 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
50 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
51 DH_GEX group out of range: 1536 !< 1024 !< 8192`

したがって、鍵交換のネゴシエーション中に、クライアントとサーバーはサポートされているアルゴリズムのリストを交換します(21行目と33行目)。 2つのリストにある最初の一致、この場合はdiffie-hellman-group-exchange-sha1を使用することに同意します。私が理解しているように、このアルゴリズムは、クライアントとサーバーがネゴシエートする必要があるビット長の範囲をサポートしています。通常の状況では、クライアントとサーバーはビット長について合意し、moduliファイルのDHプライムを使用してキーを交換します。 /etc/ssh/moduli(この最後のステートメントがvery "素人の発言"であることは知っていますが、それは大体長くて短いです)。

この場合、ビット長のネゴシエーションが失敗していると思います。 49行目で、クライアント(私)は「1536〜8192のビット長をサポートしており、3072ビットを使用したい」と言っています。ただし、サーバーは「私は1024ビットのみをサポートします」と返信します。その時点でクライアントはあきらめ、「私はあなたと話せません」と言います。これは、ここで起こっていることの合理的な説明ですか?

私が理解しているように、この時点で問題は完全にサーバー側にあります(diffie-hellman-group1-sha1のようなより弱いアルゴリズムをネゴシエートしないと仮定します)。鍵交換プロセス中に、より長いビット長をサポートするようにサーバーを変更する必要があります。

先に進む前に、これを正しく理解していることを確認したいと思います。入力を歓迎します。

19
sbrown

新しいOpenSSHを使用して非推奨のサーバーに接続する場合:

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss my.Host.com

何が起こっているのかを確認したい場合は-vを追加し、それでも機能しない場合は-o HostKeyAlgorithms = ssh-dssを追加します。

ssh -v -o HostKeyAlgorithms=ssh-dss -o KexAlgorithms=diffie-hellman-group14-sha1 my.Host.com

もちろん、/ etc/ssh/ssh_configまたは〜/ .ssh/ssh_configを編集して、以下を追加することもできます。

Host my.Host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1    

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 は、Mikrotikルーターボードの以下の修正に言及しています:

/ip ssh set strong-crypto=yes

(この回答は、同様のエラーメッセージを探すときにWeb検索でも表示されるため、ここで注意してください。)

Ssh_configを編集したり、SSHサーバーを更新したりせずにGitで使用する場合:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@Host/path-to-repository
21
Dagelf

バグ をヒットしたようです。

原因

Opensshパッケージが変更され、Diffie-Hellman Group Exchangeが扱われました。以前は、サイズ1024〜8192のキーを交換できました。セキュリティを強化し、「logjam」の脆弱性を回避するため、最小値は1536に引き上げられました。ただし、1024のみをサポートするサードパーティのssh実装で使用すると、エラーが発生します。理想的には、サードパーティのssh設定またはコードを更新して、より大きな鍵サイズを使用する必要があります。

...

リンクには3つの異なる解像度があります。管理者権限がないか、官僚機構が多すぎてより深い変更を加えることができない状況では、サーバーでSHA-2が利用可能になるのを待つ間に問題のあるアルゴリズムを取り除くことが、私にとって最良の選択肢であると思われました。 $ HOME/.ssh/configファイルでユーザーベースの方法で実行することもできます。

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
11
xmar