# ssh to system hangs at SSH2_MSG_KEXINIT, ssh in ok

## vputz

Not sure if this is a Gentoo issue or a "you don't know how to use SSH noob" issue, but I thought I'd post and offer.

I have a system I'm trying to ssh into and am mystified that ssh from Win32/cygwin works like a charm, while ssh from Gentoo hangs at "SSH_MSG_KEXINIT sent" (it is never received--this from "ssh -vvv").  If I specify "ssh -1", then it hangs at "retrieving server public key".  The server appears to be running OpenSSH 3.5p1, and I'm running whatever's current in Gentoo.  I've tried recreating identity, id_dsa, id_rsa, etc to no avail (although "ssh -vvv" does complain about whitespace in the keys, wrong format, etc).

Curiously, there is NO problem ssh'ing from the 'server' to my home machine, so I can still transfer files, and I can ssh from my home computer to a third, and from there to the server.  But it Bothers Me that it doesn't work (and that the cygwin version of ssh is working fine).

Any suggestions on how to further diagnose or fix this?  I've seen a few googled messages about servers hanging at "SSH_MSG_KEXINIT sent" but no answers.

----------

## flophousejoe

 *vputz wrote:*   

> I have a system I'm trying to ssh into and am mystified that ssh from Win32/cygwin works like a charm, while ssh from Gentoo hangs at "SSH_MSG_KEXINIT sent"

 

Whenever I see ssh key exchange failing, the first thing I check is the tcp wrappers configuration on the system running the ssh server.

If the ssh server was compiled with tcp wrappers support (in Gentoo, the "tcpd" USE flag), then the server will consult files like /etc/hosts.allow and /etc/hosts.deny after accepting the incoming connection to tcp port 22 but before starting the SSH session.  If the rules in these files disallow access from the IP address of your ssh client, then you'll see the same error that you reported when you try to connect.

If the files on the SSH server /etc/hosts.allow and /etc/hosts.deny have any contents, then check them out and see if it's possible that they're the problem.  (It's especially likely to be the source of the problem if you find a reference to the IP address of the "problem" ssh client but not to the working ssh client.)  For reference, check out the manpages tcpd(8) and hosts_access(5) .

If this isn't it, then it's possible-- albeit less likely-- that the ssh client on your Gentoo system is configured too strictly.  You can check for this really quickly by temporarily moving your ssh client's configuration out of the way (mv ~/.ssh ~/.ssh.moved) and then trying again to SSH into the problem system.  If this suddenly works, then you know that your client's configuration was to blame.  It's then up to you to play trial and error to find out which directive is causing trouble.

The two things I mentioned here came to mind first because they come up the most frequently.  I wasn't able to tell from the post whether the problem SSH server accepts the usual keyboard-interactive authentication (as opposed to certificates only), but investigating this is one of the possible avenues to pursue if the problem persists.

----------

