SSH使用问题以及解决方案(expecting SSH2_MSG_KEX_ECDH_REPLY) #44
Description
情景
公司内网的一台服务器（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连接。