I found this thread helpful, so I thought to add my experience. In short, I have a dual band wifi router/DSL modem (Arris BGW210-700) which seems to mess with some traffic moving between devices connected at 2.4GHz (my SSH server) and 5GHz (my ssh client). I can avoid this by forcing the use of 2.4GHz by both devices.
The symptom I see is the same random stalled SSH sessions as the reporter. In my case, only about 1 in 20 attempts succeed. Adding the various CLI arguments mentioned seems to change the probability of a stall a little, but none eliminate it. Running a packet capture on the client machine with wireshark, I see that the stall is followed by a frame labeled "TCP Spurious Retransmission" from server to client, and then some "TCP Dup ACK" from client to server. The frame being resent has a length of only 518 bytes, well below the 1500 byte MTU. I could successfully 'ping -s 1458 <ip>' in both directions. Wireshark confirms that 1500 byte frames were being sent. Still, I tried changing the MTU on both machines to first 1400 and then 1200. This reduced the chance of a stall to the point where SSH was almost usable. I was puzzled at this point. I suspected the wifi router as I previously had these machines working through a different (older) router, but wasn't sure how the router could be involved between two local devices. Eventually I realized that the router was bridging traffic since the two machines were connecting to different radios. I disabled the 5GHz radio on the router to force the client machine to 2.4GHz. At that point 20 of 20 connection attempts succeeded. Running the client machine (my laptop) at the lower bit rate isn't a permanent solution for me. I doubt I'll make any head way with the router though. sigh... wonderful closed firmware. I'll also mention a couple of other things I tried which made no difference. Adding "UseDNS no" to the SSH server config changed nothing. Disabling the offloading features of the server NIC with ethtool also changed nothing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1254085 Title: ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY' Status in openssh package in Ubuntu: Invalid Bug description: ssh -vvv <host> is failing for me where <host> is a VPN system. VPN is configured and connected via network-manager. Last messages from ssh (hangs forever): debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY = Workaround = $ sudo apt-get install putty $ putty <host> This works perfectly. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: openssh-client 1:6.4p1-1 ProcVersionSignature: Ubuntu 3.12.0-3.8-generic 3.12.0 Uname: Linux 3.12.0-3-generic i686 NonfreeKernelModules: nvidia ApportVersion: 2.12.7-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Fri Nov 22 15:37:18 2013 InstallationDate: Installed on 2010-10-21 (1128 days ago) InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007) RelatedPackageVersions: ssh-askpass 1:1.2.4.1-9 libpam-ssh N/A keychain 2.7.1-1 ssh-askpass-gnome 1:6.4p1-1 SSHClientVersion: OpenSSH_6.4p1 Ubuntu-1, OpenSSL 1.0.1e 11 Feb 2013 SourcePackage: openssh UpgradeStatus: Upgraded to trusty on 2013-11-01 (20 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
