ssh hang after SSH2_MSG_KEXINIT sent

[tin...@isbd.co.uk]

.... but I'm fairly sure it's not an MTU problem and that's the only
thing I can find using Google.

Other client connections to the same host work OK, even from ssh
clients on the same subnet as the ssh client that doesn't work.
Similarly the ssh client that hangs in this one particular case can
connect to other ssh host machines. One other Fedora 6 Core client
machine on the same network *does* show the same problem, an Ubuntu
and an older Fedora machine don't show the problem.

The ssh client is OpenSSH_4.3p2 on a Fedora Core 6 installation, the
host it can't connect to is OpenSSH_4.4p1 on a Slackware 11 machine.

Having done a google search for this problem I have tried setting the
MTU to 576 on both client and host, no effect at all. (I simply did
'ifconfig eth0 mtu 576' on both machines as root, is this all that's
needed?)

The client debug reads as follows:-

debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/chris/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.4
debug1: match: OpenSSH_4.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

There's a long (minutes) pause after the SSH2_MSG_KEXINIT sent.

Does anyone have any suggestions as to what might be the problem?

--
Chris Green

[ssab...@gmail.com]

Hi there,
I have the same problem, but with open SuSE 10.2.
On the same machine I have windows instalation and it works from there
with putty. Even from windows and VmPlayer with openSuSE 10.2 there is
NO problem connect to one single host.
The connection to other hosts using sshd is ok. Even to windows
servers with copSSH.
I tried change the MTU - it doesn helped.

Here is the client debug:
OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1

debug1: Remote protocol version 1.99, remote software version

OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.4

debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent

And here it HANGS!!
I tryed putty for linux and the problem persist.
Could this be something with the kernel params?
On suse machines i use different kernels: 2.6.18.2-34-xen, 2.6.18.2-34-
default.

10x to everyone

[wkja...@gmail.com]

I am seeing this problem on Debian testing (lenny) with a 2.6.18
kernel. Given the previous comments I'm starting to guess it's
something in 2.6.18. Here is a compiled list so far including my
machines.

Fedora Core 6 -> hangs
2.6.18

OpenSuse 10.2 -> hangs
2.6.18.2-34

Opensuse 10.1 -> works
2.6.16

Xubuntu 7.04 -> works
2.6.20-15.27
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006

Debian Etch -> hangs
2.6.18.dfsg.1-12etch2
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006

Debian Etch -> works
linux-image-2.6.15-1-486
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005

Debian lenny/sid -> hangs
Kernel: 2.6.18.dfsg.1-12etch2
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8e 23 Feb 2007
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

Centos 4 -> works
2.6.9-55.EL
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003

In my case I am doing the following:

Workstation A -> Nat -> Internet -> Nat -> Workstation B

The ubuntu, opensuse 10.1, Centos, and the debians following the same
network path.

[ssab...@gmail.com]

Hi there,
Finally I fond how to make a workaround!
It is a kernel parameter....bu the real problem is somewhere out
there....on the path between to machines.

so What I've done - I'v changed the kernel parameter
net.ipv4.tcp_rmem.

from
net.ipv4.tcp_rmem = 4096 87380 4194304
to
net.ipv4.tcp_rmem = 4096 87380 207520

And it worked...
I made a systl -a > file.1 on FC6 and then syscl -p file.1 on SuSE
10.2 and it worked...then diff and a lot of test...
Hope somebody can tell actually what is the problem.
The machines that I cannot ( now I can ) connect via SSH are behind
BSD firewall ( not supported by our company )....and 16 hops.
I presume that between 2 machines there a network unit which cannot
handle big traffic (may be I'm wrong )....but how to say which one?

[daw...@gmail.com]

ssabc...@gmail.com napisa (a):
[...]

> I made a systl -a > file.1 on FC6 and then syscl -p file.1 on SuSE
> 10.2 and it worked...then diff and a lot of test...
> Hope somebody can tell actually what is the problem.
> The machines that I cannot ( now I can ) connect via SSH are behind
> BSD firewall ( not supported by our company )....and 16 hops.
> I presume that between 2 machines there a network unit which cannot
> handle big traffic (may be I'm wrong )....but how to say which one?

I have the same problem.
Have you found any solution not workaround for this?

I also have a BSD system in beetween (with IPSEC).

Regards,

Dawid SQ6EMM

[Darren Tucker]

On 2007-06-12, daw...@gmail.com <daw...@gmail.com> wrote:
[...]

> I have the same problem.
> Have you found any solution not workaround for this?

Set the MTU to 1492 or less. See:
http://www.snailbook.com/faq/mtu-mismatch.auto.html

> I also have a BSD system in beetween (with IPSEC).

IPSEC is one of the usual suspects for MTU problems.

--
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.

[ssab...@gmail.com]

As I wrote before - I've tested MTU options but only on machines that
I can control!
And it didnt worked.
I don't have any other ideas.
May be you can try change the MTU on the BSD - whre IPSEC is running.
BR,
Stiliyan Sabchew

[gpc...@gmail.com]

=

C:\ICW>ssh -vvv 127.0.0.1

OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

debug2: ssh_connect: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /.ssh/identity type -1
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8
debug1: match: OpenSSH_5.8 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.6

debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

[Pierre Asselin]

I get much the same thing on my employer's laptop at work, but the
same laptop connects just fine when I take it home. I just assumed
the IT department had gotten paranoid and moved along. I rarely
need outbound ssh from work.

I'll try again tomorrow to be sure the reset occurs at the same
point.

To the newsgroup: at what point is the connection encrypted?
That could rule out deep packet inspection by a company router.

--
pa at panix dot com

[igzh...@gmail.com]

I have the same problem as yours.

[gil.s...@gmail.com]

I know this thread is stale but in case it helps someone, the fix of changing MTU to 1492 or less fixed the problem for my setup. The setup is Ubuntu 15.10 using vlan on the Ubuntu 15.10 host, and ifcfg-eth1 set to put a static ip on the interface on the vlan subnet. I was able to ping from container to container over the vlan, but could not ssh, it was hanging at SSH2_MSG_KEXINIT sent. Once the interfaces in the LXC container were set to MTU=1492 (I set it in both the LXC config file and in the ifcfg-eth1 files) ssh worked! Thanks!!

[gil.s...@gmail.com]

There's some useful additional information at this link:

https://supportkb.riverbed.com/resources/sites/SUPPORT/content/live/SOLUTIONS/24000/S24051/en_US/book-external.pdf

then go to section "3.5.4. Path MTU detection"

[chad....@gmail.com]

I had the same issue. My problem turned out to be a flaky cdc_ether driver on my USB Network Adapter. Once I took it out of the equation everything worked like a champ.

[mmore...@kertel.com]

I had the same issue with pfsense 2.4.4

I have to uncheck Disable Firewall Scrub in System > Advanced > Firewall & NAT

to make it work