我们最近应用了供应商提供的 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 组交换。以前，可以交换大小为 1024 - 8192 的密钥。最小值已提高到 1536，以提高安全性并避免“堵塞”漏洞。但是，如果与仅支持 1024 的某些第三方 ssh 实现一起使用，则会发生故障。理想情况下，应更新第三方 ssh 配置或代码以使用更大的密钥大小。
...
您可以在链接中找到 3 种不同的解决方案。在您没有管理权限或有太多官僚机构无法进行更深入的更改的情况下，在等待服务器中 SHA-2 可用时摆脱有问题的算法对我来说似乎是最好的选择。您甚至可以在 $HOME/.ssh/config 文件中以基于用户的方式执行它。
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1