1

What I try to achieve: Reach the server on LAN via OpenVPN Symptoms: SSH connection hangs on SSH2_MSG_KEXINIT

ssh -vvv emmy@10.0.0.101
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 10.0.0.101 [10.0.0.101] port 22.
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.0.0.101:22 as 'emmy'
debug1: SSH2_MSG_KEXINIT sent
^C

Server side log:

May  4 16:35:58 emmy sshd[39003]: Connection from 10.10.8.6 port 55592 on 10.0.0.101 port 22 rdomain ""
May  4 16:35:58 emmy sshd[39003]: debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
May  4 16:35:58 emmy sshd[39003]: debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
May  4 16:35:58 emmy sshd[39003]: debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x04000000
[...]
May  4 16:35:58 emmy sshd[39003]: debug1: SSH2_MSG_KEXINIT sent [preauth]
May  4 16:35:58 emmy sshd[39003]: debug3: receive packet: type 20 [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: SSH2_MSG_KEXINIT received [preauth]
May  4 16:35:58 emmy sshd[39003]: debug2: local server KEXINIT proposal [preauth]
[...]
May  4 16:35:58 emmy sshd[39003]: debug2: peer client KEXINIT proposal [preauth]
[...]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: algorithm: curve25519-sha256 [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
May  4 16:36:09 emmy sshd[39003]: Connection closed by 10.10.8.6 port 55592 [preauth]
[...]

To me that sounded like an issue with the path mtu so i tried to measure it.

1st attempt: tracepath

sudo tracepath 10.0.0.101
 1?: [LOCALHOST]                      pmtu 1500
 1:  DESKTOP-6STOO94.mshome.net                            0.218ms
 1:  DESKTOP-6STOO94.mshome.net                            0.165ms
 2:  no reply
 3:  no reply
 4:  no reply
 5:  [...]
^C

That does not seem to work. Let's test connectivity first:

ping 10.0.0.101
PING 10.0.0.101 (10.0.0.101) 56(84) bytes of data.
64 bytes from 10.0.0.101: icmp_seq=1 ttl=62 time=14.2 ms
64 bytes from 10.0.0.101: icmp_seq=2 ttl=62 time=13.9 ms
64 bytes from 10.0.0.101: icmp_seq=3 ttl=62 time=13.9 ms
64 bytes from 10.0.0.101: icmp_seq=4 ttl=62 time=14.4 ms
64 bytes from 10.0.0.101: icmp_seq=5 ttl=62 time=14.3 ms
64 bytes from 10.0.0.101: icmp_seq=6 ttl=62 time=13.8 ms
64 bytes from 10.0.0.101: icmp_seq=7 ttl=62 time=14.1 ms
64 bytes from 10.0.0.101: icmp_seq=8 ttl=62 time=14.1 ms
^C
--- 10.0.0.101 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7012ms
rtt min/avg/max/mdev = 13.835/14.087/14.392/0.184 ms

Okay, that seems to work let's try to get the path mtu with traceroute

sudo traceroute -I --mtu 10.0.0.101
traceroute to 10.0.0.101 (10.0.0.101), 30 hops max, 65000 byte packets
 1  DESKTOP-6STOO94.mshome.net (192.168.176.65)  0.140 ms F=1500  0.133 ms  0.092 ms
 2  * * *
 3  * * *
 4  * * *
 5  [...]^C

No luck either even so a normal traceroute is working

sudo traceroute -I 10.0.0.101
[sudo] password for benedikt:
traceroute to 10.0.0.101 (10.0.0.101), 30 hops max, 60 byte packets
 1  DESKTOP-6STOO94.mshome.net (192.168.176.65)  0.316 ms  0.284 ms  0.280 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * 10.0.0.101 (10.0.0.101)  14.195 ms

So I have to check manually

ping -M do -s 1500 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1500

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

MTU of 1500 is obviously to high. Let's go down from here:

ping -M do -s 500 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 500(528) bytes of data.

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

No answer at all is odd. But lets go down further.

ping -M do -s 256 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 256(284) bytes of data.
264 bytes from 10.0.0.1: icmp_seq=1 ttl=63 time=14.4 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 14.431/14.431/14.431/0.000 ms

The sweet spot seems to be 285. That explain my problem. The SSH packet is larger than that and is not allowed to fragment because of security reasons.

My question now is: How can I overcome this?

0 Answers0