最近、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(この最後のステートメントはとても「素人の言うこと」ですが、大体こんな感じです。
この場合、私が見ているのは、ビット長のネゴシエーションが失敗しているということだと思います。49 行目で、クライアント (私) は「1536 から 8192 までのビット長をサポートしており、3072 ビットを使用したい」と言っています。しかし、サーバーは「1024 ビットしかサポートしていません」と返答します。この時点で、クライアントは諦めて「あなたとは話せません」と言います。これは、ここで何が起こっているかの合理的な説明でしょうか?
私の理解では、現時点では問題は完全にサーバー側にあります ( のような弱いアルゴリズムをネゴシエートしないと仮定した場合diffie-hellman-group1-sha1)。キー交換プロセス中に、より大きなビット長をサポートするようにサーバーを変更する必要があります。
先に進む前に、これを正しく理解しているかどうか確認したいと思います。ご意見をお待ちしております。
答え1
新しい 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/6069Mikrotik ルーターボードに関する次の修正について言及しています。
/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
これに当たったようですバグ。
原因
Diffie-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