我們最近為 OpenSSH 應用了供應商提供的補丁。該補丁禁用了一些密鑰交換協議，以應對最近的 Logjam 攻擊。應用此補丁後，我們無法與一些供應商透過 sftp 交換文件，因為連接協商失敗（可能是由於已棄用的密鑰交換演算法）。
在與我們的供應商交談之前，我只想驗證一下我們所看到的一些事情。以下是與問題供應商之一的 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 行）。他們同意使用兩個列表中找到的第一個匹配項，在本例中為diffie-hellman-group-exchange-sha1。據我了解，該演算法支援客戶端和伺服器必須協商的一系列位元長度。在正常情況下，客戶端和伺服器就位長度達成一致，並使用文件中的 DH 素數交換金鑰moduli，例如/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/6069提到 Mikrotik Routerboards 上的以下修復：
/ip ssh set strong-crypto=yes
（在這裡注意這一點是因為在尋找類似的錯誤訊息時，這個答案也會出現在網路搜尋中。）
如果您想透過 Git 使用它而不編輯 ssh_config 或更新 SSH 伺服器：
GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository
答案2
看來你已經擊中了這個漏洞。
原因
對 openssh 套件進行了更改，處理 Diffie-Hellman Group Exchange。以前，可以交換大小為 1024 - 8192 的金鑰。為了增強安全性並避免「logjam」漏洞，最小值已提高到 1536。但是，如果與某些僅支援 1024 的第三方 ssh 實作一起使用，則會發生故障。理想情況下，應更新第 3 方 ssh 配置或代碼以使用更大的密鑰大小。
…
您可以在連結中找到 3 種不同的解析度。在您沒有管理權或有太多官僚機構無法進行更深入更改的情況下，在等待伺服器中的 SHA-2 可用性時擺脫有問題的演算法對我來說似乎是最佳選擇。您甚至可以在 $HOME/.ssh/config 檔案中以基於使用者的方式執行它。
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1