subject:"\[Bug 1254085\] Re\: ssh fails to connect to VPN host \- hangs at 'expecting SSH2_MSG_KEX_ECDH

[Bug 1254085] Re: ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY'

2020-09-27 Thread mdavidsaver

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 ' 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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254085

Title:
  ssh fails to connect to VPN host - hangs at 'expecting
  SSH2_MSG_KEX_ECDH_REPLY'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1254085] Re: ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY'

2018-06-29 Thread Simon Clift

My $0.02.  I don't disagree that this is an MTU problem on the path, and
that OpenSSH could be smarter about this, but my fix was to specify the
key exchange algo.

   ssh -o KexAlgorithms=ecdh-sha2-nistp521 f...@bar.com

replacing the algorithm with one that the server says it supports.

Not working:
  * MTU probing fix (#32) didn't work for me, net.ipv4.tcp_mtu_probing to 1 or 
2.
  * Specification of the cipher (#6) as in ssh -c.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254085

Title:
  ssh fails to connect to VPN host - hangs at 'expecting
  SSH2_MSG_KEX_ECDH_REPLY'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1254085] Re: ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY'

2017-01-22 Thread fhsm

Update to my comment above (#37):

I was able to connect to Box2 from OS X 10.11. I tried once more by
mistake and was shocked that it suddenly worked (albeit with a long
connection lag). With more testing I found I could connect from 10.11 to
Box2 maybe 1/25 times (as I said, crazy making). I wasn't ever able to
get to Box2 from Box1 despite trying numerous times. Long story short it
looks like the Ubuntu SSH client is the most particular vs least able to
win the race, followed by that in 10.11, followed by 10.9 which always
connected without a problem. Interestingly when I switched to keys 10.11
was much more likely to connect (1/5 times). The switch to keys had no
effect on Box1's inability to connect to Box2. So as with #36 I'd say
Ubuntu's ssh client gave the worst experience here - vs - is actually
the best but just needs an error message explaining why it's electing to
protect me from (...?) vs "working" as my other clients did.


For those curious about the sshd aspect of the story I did finally track down a 
fix for Box2. Box1 and Box2 are both dual nic systems. They were configured 
with eth0 as static and eth1 dhcp. Plugging eth1 and letting it obtained a dhcp 
lease / taking that interface out of the config fixed Box2. Having the 
interface configured but the jack unplug produced the client dependent 
connection issues I outlined in #37. Box1 had the exact same interface config 
(eth1 looking for a dhcp lease but not being plugged in) without any problem. 
They are both full Intel systems but totally different hardware. Seems like the 
kernel abstraction leaking hardware details up the stack but understandable 
given both were arguably misconfigured. Imagine how annoying it would be in a 
dual nic system to have a port go out and suddenly arbitrarily be unable to 
connect to sshd with anything other than an old copy of OS X. 

TL;DR - my 16.10 ssh client didn't work when others did and failed
silently. This may be Ubuntu being smart. It may be Ubuntu being broken.
Either repair or an informative error would make the experience better
than / comparable to others.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254085

Title:
  ssh fails to connect to VPN host - hangs at 'expecting
  SSH2_MSG_KEX_ECDH_REPLY'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1254085] Re: ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY'

2017-01-20 Thread fhsm

I'm running into hung ssh connection and it is crazy making because I'm
getting inconsistent behavior across 16.10 boxes.

I've got two newly installed 16.10 boxes ($ ssh -V: OpenSSH_7.3p1
Ubuntu-1, OpenSSL 1.0.2g  1 Mar 2016). I'll call them Box1 and Box2.
They are in in adjacent ports on switch that has not had any changes in
years and on which all other systems are functioning.

I've got four clients: one OS X 10.9 (OpenSSH_6.2p1,OSSLShim 0.9.8r 8
Dec 2011), OS X 10.11 (OpenSSH_6.9p1, LibreSSL 2.1.8), Box1, and Box2.

I can connect to Box1 from the other three clients without any problem.
Works as expected.

I can ONLY connect to Box2 from OS X 10.9 and itself (i.e. ssh
me@localhost). I cannot get to it from Box1, I cannot get to it from OS
X 10.11. I have swapped the two OS X boxes around on the network and
also the two 16.10 boxes such that I'm confident that the ability to
connect is a function of the client-server combination not the network
link between them. ssh -vvv into Box2 from all of the failing clients
hangs as above, expecting SSH2_MSG_KEX_ECDH_REPLY.

This behavior / bug is so perplexing I'm unsure of it's relevance. I see two 
factors of interest:
 - Two ubuntu 16.10 sshds are behaving differently despite stock config across 
the two;
 - The ubuntu 16.10 is unable to connect to an sshd that one of two OS X ssh 
clients is able to connect two.

Since the two just got installed they haven't had much time to diverge.
The only differences between box1 and box2 are: (1) box2 is a few
updates behind and (2) although both have LXD installed only box2 has
had a container launched on it. Unfortunately prior to racking only the
10.9 system had ssh-ed into these boxes.

I'm going to sit on this for now in case someone interesting in trying
to get the Ubuntu ssh client to function - or - someone curious about
the divergent behavior of the Ubuntu sshd can give guidance on how to
turn this from a odd +1 report into something more useful. If not I'll
do a little more troubleshooting (install the pending updates
[initramfs-tools initramfs-tools-bin initramfs-tools-core isc-dhcp-
client isc-dhcp-common libglib2.0-0 libglib2.0-data liblxc1 lxc-common],
purge LXD) to see if I stumble onto something useful and failing that
nuke and pave.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254085

Title:
  ssh fails to connect to VPN host - hangs at 'expecting
  SSH2_MSG_KEX_ECDH_REPLY'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1254085] Re: ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY'

2016-11-19 Thread netmasta10bt

There is a problem with 'OpenSSH' client not connecting while 'Putty'
client does work given the same network settings.  This was my finding
almost 3 years ago.

Given that another client does work - there is something OpenSSH Client
can do to resolve the issue.

Ubuntu distributes OpenSSH client in it's core distribution.  As such
this is a valid issue with Ubuntu and should remain open until one of
the following conditions are met:

1) The issue is fixed in OpenSSH client and connection succeeds as it
does in Putty and Ubuntu releases a package that resolves it.

2) The OpenSSH package inserts a sane timeout on 'expecting
SSH2_MSG_KEX_ECDH_REPLY' and issue's an error to the user instead of
hanging for a connection, leaving a poor user experience.  Inform the
user that the software is not adequate in its ability tolerate uncertain
MTU settings, and suggest a more robust client such as Putty.

3) Ubuntu removes OpenSSH client from its core distribution.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254085

Title:
  ssh fails to connect to VPN host - hangs at 'expecting
  SSH2_MSG_KEX_ECDH_REPLY'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1254085] Re: ssh fails to connect to VPN host - hangs at 'expecting SSH2_MSG_KEX_ECDH_REPLY'

2016-11-18 Thread ChristianEhrhardt

Hi everybody,
this is coming up over and over again and not only on Ubuntu but on various
Distributions.

As outlined before the error is an effect of broken path MTU discovery.
This could be Firewall, broken Router software, ... , bad local MTU config, ...
many potential sources.

It is nothing that "openssh" nor Ubuntu's openssh packaging can really
fix.

The real "fix" is to fixup the network configuration wherever it is
broken for correct PMTU discovery (or fix the local net/mtu
configuration if that is the issue).

The mentioned workaround is nice - thank you bs for the mentioning - as
it gives user unable to configure the network a way to work around the
issue. The way it works is that it switches the MTU discovery to
different modes (https://www.kernel.org/doc/Documentation/networking/ip-
sysctl.txt).

That said one might argue why the default mode is disabled, but look at since
when this is the default:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5d424d5a674f782d0659a3b66d951f412901faee
That is a decade ago and never changed (these days namespacified, but still 0).
So I think this as default is set in stone as much as everything else that
survives that long.

All that outlined I think we have to mark the bug invalid/incomplete as
it should be considered a local configuration issue IMHO. Please of you
object please set it back to confirmed and explain why you think so -
and if possible please also mention how you'd suggest to approach the
case.

69 matches

Mail list logo