SSH:DH_GEXグループが範囲外


18

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

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

# ssh -vv user@host.domain.com
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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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,rijndael-cbc@lysator.liu.se
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,rijndael-cbc@lysator.liu.se
25 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
28 debug2: kex_parse_kexinit: none,zlib@openssh.com,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,hmac-sha256@ssh.com
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,hmac-sha256@ssh.com
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この最後のステートメントは非常に「素人の話」ですが、それはおおよそ長短ですそれ)。

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

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

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


1
あなたはそれを正しく読んでいます。一体何がもう一方の端にありますか?これは一般的なsshサーバーのようには見えません。
マイケルハンプトン

サーバーが何かわかりません。両方とも銀行である2つの異なるベンダーで同じ問題が発生しています。どちらのサーバーもセッションで自身を識別しません(これは驚くことではありません)。
ブラウン

銀行はセキュリティの上にもう少しあると思いますが、悲しいかな...
マイケルハンプトン

2
「GXSSSHD_Comments」を検索すると、さまざまなSFTPクライアントフォーラムでコメントが表示されます。これは、サーバーがGXS MFTアプリケーションであることを示唆しているようです。
カスタリア

回答:


21

新しい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 Routerboardsの次の修正に言及しています。

/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

2
これはsftpでも動作します
bao7uo

11

このバグが発生したようです。

原因

Diffshie-Hellman Group Exchangeに対処するため、opensshパッケージに変更が加えられました。以前は、サイズが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
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.