linux – SSH：DH_GEX组超出范围

概述我们最近为OpenSSH应用了供应商提供的补丁.该补丁禁用了一些密钥交换协议以响应最近的Logjam攻击.应用此补丁后,我们有一些供应商,我们无法通过sftp交换文件,因为连接协商失败(可能是由于弃用的密钥交换算法). 我想在与供应商交谈之前验证我们看到的一些事情.以下是与其中一个问题供应商(添加的行号)的示例SSH会话： # ssh -vv [email protected] Ope 我们最近为OpenSSH应用了供应商提供的补丁.该补丁禁用了一些密钥交换协议以响应最近的Logjam攻击.应用此补丁后,我们有一些供应商,我们无法通过sftp交换文件,因为连接协商失败(可能是由于弃用的密钥交换算法).

我想在与供应商交谈之前验证我们看到的一些事情.以下是与其中一个问题供应商(添加的行号)的示例SSH会话：

# ssh -vv [email protected] OpenSSH_6.2p2,OpenSSL 0.9.8j-fips 07 Jan 200902 deBUG1: Reading configuration data /etc/ssh/ssh_config03 deBUG1: /etc/ssh/ssh_config line 20: Applying options for *04 deBUG2: ssh_connect: needpriv 005 deBUG1: Connecting to host.domain.com [1.2.3.4] port 22.06 deBUG1: Connection established.07 deBUG1: permanently_set_uID: 0/008 deBUG1: IDentity file /root/.ssh/ID_rsa type -109 deBUG1: IDentity file /root/.ssh/ID_rsa-cert type -110 deBUG1: IDentity file /root/.ssh/ID_dsa type -111 deBUG1: IDentity file /root/.ssh/ID_dsa-cert type -112 deBUG1: IDentity file /root/.ssh/ID_ecdsa type -113 deBUG1: IDentity file /root/.ssh/ID_ecdsa-cert type -114 deBUG1: Enabling compatibility mode for protocol 2.015 deBUG1: Local version string SSH-2.0-OpenSSH_6.216 deBUG1: Remote protocol version 2.0,remote software version GXSSSHD_Comments17 deBUG1: no match: GXSSSHD_Comments18 deBUG2: fd 3 setting O_NONBLOCK19 deBUG1: SSH2_MSG_KEXINIT sent20 deBUG1: SSH2_MSG_KEXINIT received21 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-sha122 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-dss23 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] deBUG2: kex_parse_kexinit: aes128-ctr,[email protected] 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-9626 deBUG2: kex_parse_kexinit: [email protected],hmac-md5-9627 deBUG2: kex_parse_kexinit: none,[email protected],zlib28 deBUG2: kex_parse_kexinit: none,zlib29 deBUG2: kex_parse_kexinit:30 deBUG2: kex_parse_kexinit:31 deBUG2: kex_parse_kexinit: first_kex_follows 032 deBUG2: kex_parse_kexinit: reserved 033 deBUG2: kex_parse_kexinit: diffIE-hellman-group1-sha1,diffIE-hellman-group-exchange-sha25634 deBUG2: kex_parse_kexinit: ssh-dss,ssh-rsa35 deBUG2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,arcfour12836 deBUG2: kex_parse_kexinit: aes128-cbc,arcfour12837 deBUG2: kex_parse_kexinit: hmac-md5,hmac-md5-96,hmac-sha256,[email protected] deBUG2: kex_parse_kexinit: hmac-md5,[email protected] deBUG2: kex_parse_kexinit: none,zlib40 deBUG2: kex_parse_kexinit: none,zlib41 deBUG2: kex_parse_kexinit:42 deBUG2: kex_parse_kexinit:43 deBUG2: kex_parse_kexinit: first_kex_follows 044 deBUG2: kex_parse_kexinit: reserved 045 deBUG2: mac_setup: found hmac-md546 deBUG1: kex: server->clIEnt aes128-ctr hmac-md5 none47 deBUG2: mac_setup: found hmac-md548 deBUG1: kex: clIEnt->server aes128-ctr hmac-md5 none49 deBUG1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent50 deBUG1: expecting SSH2_MSG_KEX_DH_GEX_GROUP51 DH_GEX group out of range: 1536 !< 1024 !< 8192`

因此,在密钥交换协商期间,客户端和服务器交换它们支持的算法列表(第21和33行).他们同意使用两个列表中的第一个匹配项,在本例中为diffIE-hellman-group-exchange-sha1.据我了解,该算法支持客户端和服务器必须协商的一系列位长度.在正常情况下,客户端和服务器就比特长度和交换密钥达成一致,利用来自模数文件的DH prime,例如,/ etc / ssh / moduli(我知道这最后一句话非常“外行说话”,但这大致是它的长短).

在这种情况下,我认为我看到的是比特长度协商失败.在第49行,客户端(我)说“我支持1536和8192之间的位长,并希望使用3072位.”但是,服务器回复并说“我只支持1024位”.客户放弃了,并说：“我不能跟你说话.”这是对这里发生的事情的合理描述吗？

据我所知,问题完全在服务器端(此时我们不会像diffIE-hellman-group1-sha1那样协商一个较弱的算法).必须修改服务器以在密钥交换过程中支持更大的比特长度.

在继续之前,我想确保我正确理解这一点.输入表示赞赏.

解决方法 如果要使用较新的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

(注意这一点,因为在寻找类似的错误消息时,这个答案也出现在网络搜索上.)

如果你想在不编辑ssh_config或更新SSH服务器的情况下通过Git使用它：

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffIE-hellman-group14-sha1" git clone ssh://user@host/path-to-repository

总结

以上是内存溢出为你收集整理的linux – SSH：DH_GEX组超出范围全部内容，希望文章能够帮你解决linux – SSH：DH_GEX组超出范围所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。