ssh connection stop at "debug1: SSH2_MSG_KEXINIT sent" - problem with linux 2.6 and vista

View: New views
3 Messages — Rating Filter:   Alert me  

ssh connection stop at "debug1: SSH2_MSG_KEXINIT sent" - problem with linux 2.6 and vista

by marco69v :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

Hi all,
I've just read something about hang after "debug1: SSH2_MSG_KEXINIT
sent" message but is not so clear what is needed to do, specially if
the server is not handled by you(me)...

Let me try to explain my situation:

Clients:
Linux with OpenSSH_4.5p1, OpenSSL 0.9.8b 04 May 2006
Windows with any sw client
Server (claim to be):
freeBSD with Remote protocol version 2.0, remote software version
OpenSSH_2.9.9p2

both kind of clients stop with the following trace:
OpenSSH_4.5p1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to omitted [omitted] 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 2.0, remote software version OpenSSH_2.9.9p2
debug1: match: OpenSSH_2.9.9p2 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent


But if, with any clients from both OS, we use a socks that is a linux
kernel 2.4 everything goes on its way (go ok)

So, my question is:
is there really nothing to manage in the kernel parameter (for linux)
or in the registry (for windows) to try to backward tcp packet to
kernel 2.4 ?

Hope I was clear enough ... :D

Thank in advance.

MV

Re: ssh connection stop at "debug1: SSH2_MSG_KEXINIT sent" - problem with linux 2.6 and vista

by dkensiski :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

So I'm not sure if you're still having this problem or not (it is 2 months later), but I have been fighting with it myself for several months and have gotten nowhere.  In my case, the delay was caused by my local SSH client trying to look up Kerberos credentials, but I am not using Kerberos!  I was able to resolve the issue by simply adding the following to the end of /etc/ssh_config:

    GSSAPIAuthentication no
    GSSAPIKeyExchange no

No restart necessary -- the next time you initate an SSH conneciton, it should take effect.

I had one or two stubborn systems where it still happened and I resolved those by putting the same lines in /etc/sshd_config so it changed the way the server behaves.  In this case, you'll have to restart the SSH daemon for the changes to take effect.

Hope it helps!
--Dave

Re: ssh connection stop at "debug1: SSH2_MSG_KEXINIT sent" - problem with linux 2.6 and vista

by marco69v :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

Thank a lot,
Yes.
The problem is still alive for me and eighter with your hints I was not able to solve it.

GSSAPIKeyExchange no
gives me also an error (probably is only for windows version?)

thanks again,

By

dkensiski wrote:
So I'm not sure if you're still having this problem or not (it is 2 months later), but I have been fighting with it myself for several months and have gotten nowhere.  In my case, the delay was caused by my local SSH client trying to look up Kerberos credentials, but I am not using Kerberos!  I was able to resolve the issue by simply adding the following to the end of /etc/ssh_config:

    GSSAPIAuthentication no
    GSSAPIKeyExchange no

No restart necessary -- the next time you initate an SSH conneciton, it should take effect.

I had one or two stubborn systems where it still happened and I resolved those by putting the same lines in /etc/sshd_config so it changed the way the server behaves.  In this case, you'll have to restart the SSH daemon for the changes to take effect.

Hope it helps!
--Dave