Solaris

Well, if you have root access on the server you can truss the running sshd process and see what's hanging:

Code:

truss -f -d -vall -o /output/file/name -p PID

Where PID is the process id of the sshd process that's actually listening on port 22. It'll probably be the only one with a parent PID of 1 in the global zone. Just make sure the output file name is to a secure path because the file it generates will capture everything.

That will show you where the hang is happening. But you need root access and you'll need to dig through the output file to find it. If you can, tail the file while you're logging in to see the timeout as it rolls by and see what to look for.

Just a guess, but is your remote host listed in the host file in the local zone, but not in the global zone? Or are there differences in the nameservers used for DNS lookups? You can try doing an nslookup on your remote host's IP address in both zones.

OK so, for posterity, the solution was:

- no /etc/hostname.xxx file - when the machine was first installed it could not get on to the network due to switch/router config, so this file was not created. This meant that after reboot the network was not up and required setting up again
- incorrectly configured hosts file - the host name was against the local loopback address, so the network service could not match the network card to the IP address.

This meant that when UseDNS=no was set in /etc/ssh/sshd_config it just hung ssh. Once the above issues were resolved, adding UseDNS=no then did sort out the long hangs since we do not have DNS ports and servers running on our back-end DB server subnets.

I did try trussing the process as suggested, achenle, and I saw the process hanging on door_calls, but this didn't tell me much in this case, as it was indeed reverse DNS lookups which were causing the problem.

Moral?: re-check your basic config files and get your colleagues to check them if they look OK to you! Thanks all for your help and suggestions.