On 09/20/2015 03:25 AM, Darren Tucker wrote:> I suspect a path mtu problem. The key exchange packet is one of the > first large ones in an SSH connection so it tends to show up such problems. > > Seehttp://www.snailbook.com/faq/mtu-mismatch.auto.html > <http://www.snailbook.com/faq/mtu-mismatch.auto.html>Has this been changed? SSH used to work fine on my old machine. My local mtu and server mtu are higher than required. Therefore the only thing I could expect would be a lower mtu on the vpn. Has this changed in recent versions. As previously I was using OSX I expect the OpenSSH version was older. Still strange to me that it worked before and not now. I will test tomorrow to see if connecting on the actual network solves the issue.
On 20 September 2015 at 11:28, Carlo Abelli <carlo.abelli at gmail.com> wrote:> On 09/20/2015 03:25 AM, Darren Tucker wrote: >> I suspect a path mtu problem. The key exchange packet is one of the >> first large ones in an SSH connection so it tends to show up such problems. >> >> Seehttp://www.snailbook.com/faq/mtu-mismatch.auto.html >> <http://www.snailbook.com/faq/mtu-mismatch.auto.html> > > Has this been changed? SSH used to work fine on my old machine. My local > mtu and server mtu are higher than required. Therefore the only thing I > could expect would be a lower mtu on the vpn. Has this changed in recent > versions. As previously I was using OSX I expect the OpenSSH version was > older. Still strange to me that it worked before and not now. I will > test tomorrow to see if connecting on the actual network solves the issue.It is common for VPNs to introduce lower MTU limits and to not correctly send ICMP code 3 type 4 packets. This isn't so much of an SSH problem as it is a misconfiguration on the network path to the destination. See https://www.ietf.org/rfc/rfc2923.txt for further examples. -- Eitan Adler
On 20/09/15 20:28, Carlo Abelli wrote:> On 09/20/2015 03:25 AM, Darren Tucker wrote: >> I suspect a path mtu problem. The key exchange packet is one of the >> first large ones in an SSH connection so it tends to show up such problems. >> >> Seehttp://www.snailbook.com/faq/mtu-mismatch.auto.html > Has this been changed? SSH used to work fine on my old machine. My local > mtu and server mtu are higher than required. Therefore the only thing I > could expect would be a lower mtu on the vpn. Has this changed in recent > versions. As previously I was using OSX I expect the OpenSSH version was > older. Still strange to me that it worked before and not now. I will > test tomorrow to see if connecting on the actual network solves the issue.New versions tend to add more key exchanges, so yes. You can also use ssh -o KexAlgorithms=<algos use by dropbear> to test the hypothesis.
Thanks all. I'll check tomorrow if it is indeed the VPN by connecting to the network and testing. On Sunday, September 20, 2015, ?ngel Gonz?lez <keisial at gmail.com> wrote:> On 20/09/15 20:28, Carlo Abelli wrote: > >> On 09/20/2015 03:25 AM, Darren Tucker wrote: >> >>> I suspect a path mtu problem. The key exchange packet is one of the >>> first large ones in an SSH connection so it tends to show up such >>> problems. >>> >>> Seehttp://www.snailbook.com/faq/mtu-mismatch.auto.html >>> >> Has this been changed? SSH used to work fine on my old machine. My local >> mtu and server mtu are higher than required. Therefore the only thing I >> could expect would be a lower mtu on the vpn. Has this changed in recent >> versions. As previously I was using OSX I expect the OpenSSH version was >> older. Still strange to me that it worked before and not now. I will >> test tomorrow to see if connecting on the actual network solves the issue. >> > New versions tend to add more key exchanges, so yes. You can also use > ssh -o KexAlgorithms=<algos use by dropbear> to test the hypothesis. > > >-- Thanks, Carlo
On Mon, Sep 21, 2015 at 6:05 AM, ?ngel Gonz?lez <keisial at gmail.com> wrote:> > New versions tend to add more key exchanges, so yes. You can also use > ssh -o KexAlgorithms=<algos use by dropbear> to test the hypothesis. >Note that this is not a definitive test because the server will still offer its full list of key exchange and cipher methods, so depending on exactly what and where the problem is, this could still potentially tickle MTU blackhole problems. You'd need to restrict the OpenSSH server's KexAlgorithms, HostKeyAlgorithms, Ciphers and Compression settings for an accurate test, and note that this configuration would be significantly less safe than OpenSSH's defaults. I'd try the MTU thing in the link I sent you. Alternatively, if you have access to both ends via some other means, find the ssh connection in the output of "netstat" on both sides and check if the SendQ column stays non-zero indicating that the network traffic never get acknowledged. $ telnet openssh 22 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_7.1 SSH-2.0-me t ???? ?P6???}:? Ydiffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1'ssh-rsa,ecdsa-sha2-nistp256, ssh-ed25519lchacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr, aes128-gcm at openssh.com,aes256-gcm at openssh.comlchacha20-poly1305@openssh.com ,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com?umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-sha1?umac-64-etm at openssh.com, umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com, hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 none, zlib at openssh.com none,zlib at openssh.com ^] telnet> quit Connection closed $ telnet dropear 22 Trying 192.168.34.1... Connected to rtr. Escape character is '^]'. SSH-2.0-dropbear_0.46 SSH-2.0-me ?? ?Hlm?O?)d??8? diffie-hellman-group1-sha1ssh-rs3des-cb3des-cbc hmac-sha1,hmac-md5 hmac-sha1,hmac-md5 none none ?h8u??! ^] telnet> quit Connection closed -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.