Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
johnnian opened this issue Jan 25, 2018 · 9 comments
Open

Comments

@johnnian
Copy link
Owner

情景

公司内网的一台服务器(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 root@123.123.123.123
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,curve25519-sha256@libssh.org,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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,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,curve25519-sha256@libssh.org,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: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
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: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com 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连接。

参考链接

@GeekHades
Copy link

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

@DingGuodong
Copy link

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

@ssoft-wankun
Copy link

ssoft-wankun commented Oct 14, 2022

also fixed the problem of vscode ssh extension.
thanks.

@johnnian
Copy link
Owner Author

also fixed the problem of vscode ssh extension.

thanks.

:)

@dehengxu
Copy link

dehengxu commented Dec 7, 2022

No used, ssh handshaking disturbed by chinese gfw

@govinl
Copy link

govinl commented Feb 22, 2023

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

@methol
Copy link

methol commented Mar 15, 2023

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

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

@peterwoo339
Copy link

worked like a charm for me! Thanks for sharing!

@windring
Copy link

windring commented Jan 2, 2024

非root用户用不了ifconfig怎么办

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants