Blog icon indicating copy to clipboard operation
Blog copied to clipboard
verified publisher icon johnnian

SSH使用问题以及解决方案(expecting SSH2_MSG_KEX_ECDH_REPLY)

Open johnnian opened this issue 7 years ago • 9 comments

情景

公司内网的一台服务器（CentOS 7.4）无法通过SSH连接登录 阿里云服务器（CentOS7.4）

一开始以为是阿里云把内网服务器的请求IP过滤掉，然后又试了下其他服务商的服务器，有的时候可以SSH登录，又有的时候无法SSH登录。虽然SSH登录不上，但是远程服务器的IP还是可以PING通。

除了局域网这台服务器外，其他电脑都可以SSH到阿里云服务器，这就排出了阿里云过滤IP的问题（因为连的都是同一台局域网路由器，出口的IP地址都是一样的）。

这样，问题就定位到SSH的问题，打开SSH的调试，发现了现象：

SSH登录日志的最后，总是卡在：

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

完整的日志如下：

SSH Debug 日志

[root@localhost ~]# ssh -vvv [email protected]
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 47.100.31.179:22 as 'root'
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
^@Connection closed by 123.123.123.123 port 22

一开始看日志，还以为是公私钥文件找不到:

debug1: key_load_public: No such file or directory

然后对比了正常SSH登录，也会提示这个问题，而且StackOverFlow上也有人说，这个不是问题:

debug1: key_load_public: No such file or directory is not an error. Just a debug message. The key is rejected on the server side and without information from the server log, it is not possible to help you

然后，问题就定位到最后一行的日志：

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

解决方法

下面方法可以解决：

设置网卡接口的MTU值，改成：1200，测试后，确实会生效。

临时生效的配置：

[root@localhost ~]# ifconfig
enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.102  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::af7e:86da:a424:53fe  prefixlen 64  scopeid 0x20<link>
        ether d8:9e:f3:10:7a:11  txqueuelen 1000  (Ethernet)
        RX packets 814  bytes 92802 (90.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 561  bytes 159798 (156.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xf7e80000-f7ea0000

[root@localhost ~]# ifconfig enp0s31f6 mtu 1200

永久生效的配置：

[root@localhost ~]# vi /etc/sysconfig/network-scripts/ifcfg-enp0s31f6
MTU=1200            #MTU设置

[root@localhost ~]# systemctl restart network

原理

MTU（Maximum Transmission Unit）：最大传输单元，是指一种通信协议的某一层上面所能通过的最大数据包大小（以字节为单位）。最大传输单元这个参数通常与通信接口有关（网络接口卡、串口等）.(摘自维基百科)

从维基百科种看到：

这里的MTU所指的是无需分段的情况下，可以传输的最大IP报文（包含IP头部，但不包含协议栈更下层的头部）。

下面是普通媒体的MTU表：

网络 MTU(Byte)
超通道 65535
16Mb/s令牌环 17914
4Mb/s令牌环 4464
FDDI 4352
以太网 1500
IEEE 802.3/802.2 1492
X.25 576
点对点（低时延） 296

对于使用AUTOSSH建立隧道：

  • 传输模式，MTU值最大是：1440
  • 隧道模式，MTU值最大是：1420

所以，出现这个现象的原因也就清楚了： 本身以太网的MTU是1500，而隧道的MTU值1400左右，比以太网的小，因此，以太网发出去的包就被拒绝了，最终导致无法建立SSH连接。

参考链接

johnnian avatar Jan 25 '18 08:01 johnnian

It doesn't work! I dont know why case this question?

GeekHades avatar Mar 12 '19 09:03 GeekHades

It's work fine! Change mtu to 1420 also work fine~

lw939109 avatar Apr 23 '20 22:04 lw939109

I suffered this problem today(20210928), and it's works on CentOS7 in Aliyun ECS! Thanks for sharing this.

DingGuodong avatar Sep 28 '21 06:09 DingGuodong

also fixed the problem of vscode ssh extension. thanks.

ssoft-wankun avatar Oct 14 '22 15:10 ssoft-wankun

also fixed the problem of vscode ssh extension.

thanks.

：）

johnnian avatar Oct 29 '22 01:10 johnnian

No used, ssh handshaking disturbed by chinese gfw

dehengxu avatar Dec 07 '22 00:12 dehengxu

I just ran into the same problem on Ubuntu 20.04, this solution solves the problem, thank you for sharing

govinl avatar Feb 22 '23 15:02 govinl

https://serverfault.com/questions/592059/debug1-expecting-ssh2-msg-kex-dh-gex-group

我也遇到了一样的问题，这篇文章第一个回复解决了我的问题

methol avatar Mar 15 '23 15:03 methol

worked like a charm for me! Thanks for sharing!

peterwoo339 avatar Sep 11 '23 12:09 peterwoo339

非root用户用不了ifconfig怎么办

windring avatar Jan 02 '24 08:01 windring