Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a Cygwin machine that runs sshd. When I try to login the machine with SSH, it takes a while to get a response.

With the command ssh -v user@cygwin, I see that there are two commands that takes minutes.

debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to pspc [10.0.40.177] port 22.
debug1: Connection established.
debug1: identity file /Users/smcho/.ssh/identity type -1
debug1: identity file /Users/smcho/.ssh/id_rsa type -1
debug1: identity file /Users/smcho/.ssh/id_dsa type -1 <---

And

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent <---

After some Googling, I think it is caused by windows port 113 being firewalled. (http://www.cygwin.com/ml/cygwin/2009-03/msg00380.html)

How can I solve this problem? How can I return from identify and SSH2_...IT sent quickly?

share|improve this question

migrated from stackoverflow.com Feb 17 '10 at 19:32

This question came from our site for professional and enthusiast programmers.

    
What if you try to connect to that cygwin-machine from that same cygwin-machine? Like ssh -v user@localhost? –  Arjan Feb 18 '10 at 7:07
    
By the way: you cannot tell exactly if that "identify" line is causing the delays. That might very well have been completed, after which the server is doing something else. I guess peeking into the server logs might give some insight. Could you try with another client machine, just to be sure it's not the client that's causing the delays? –  Arjan Feb 18 '10 at 7:29
    
I ran in cygwin this command 'ssh -v user@localhost', and the result is exactly the same. –  prosseek Feb 18 '10 at 17:44
    
So, what about the server logs on that cygwin machine? –  Arjan Feb 19 '10 at 7:58
    
@Arjan : there seems to be 'no' change in /var/log/ directory including sshd.log. –  prosseek Feb 25 '10 at 16:04
show 1 more comment

2 Answers 2

Apart from indeed opening up IDENT port 113 towards the SSH client (so the server can try to connect to that), you might have some luck adding UseDNS no to sshd_config.

And I doubt it will help you (the client knows where to find the server, so it's not the 1st bullet, you tried the 2nd bullet, and the delays are longer than 10 seconds so the other bullets don't apply), but for the archives the OpenSSH FAQ states:

ssh(1) takes a long time to connect or log in

Large delays (more that 10 seconds) are typically caused a problem with name resolution:

  • Some versions of glibc (notably glibc 2.1 shipped with Red Hat 6.1) can take a long time to resolve "IPv6 or IPv4" addresses from domain names. This can be worked around with by specifying AddressFamily inet option in ssh_config. [On the client; AvB.]
  • There may be a DNS lookup problem, either at the client or server. You can use the nslookup command to check this on both client and server by looking up the other end's name and IP address. In addition, on the server look up the name returned by the client's IP-name lookup. You can disable most of the server-side lookups by setting UseDNS no in sshd_config. [On the server, AvB.]

Delays less than 10 seconds can have other causes.

  • OpenSSH releases prior to 3.8 had an moduli file with moduli that were just smaller than what sshd would look for, and as a result, sshd would end up using moduli significantly larger than requested, which resulted in a speed penalty. Replacing the moduli file will resolve this (note that in most cases this file will not be replaced during an upgrade and must be replaced manually).
  • OpenSSH releases prior to 3.8 had a flaw in ssh that would cause it to request moduli larger than intended (which when combined with the above resulted in significant slowdowns). Upgrading the client to 3.8 or higher will resolve this issue.
  • If either the client or server lack a kernel-based random number device (eg Solaris < 9, AIX < 5.2, HP-UX < 11.11) and no substitute is available (eg prngd) it's possible that one of the programs called by ssh-rand-helper to generate entropy is hanging. This can be investigated by running it in debug mode:

    /usr/local/libexec/ssh-rand-helper -vvv

    Any significant delays should be investigated and rectified, or the corresponding commands should be removed from ssh_prng_cmds.

share|improve this answer
    
I tried, but it didn't work. –  prosseek Feb 18 '10 at 2:47
    
It takes around 50 secs to login, so it's definitely the first category. And it's very likely a DNS lookup problem. But it looks like that there is only one option for this - 'UseDNS no' which doesn't work for this case. –  prosseek Feb 22 '10 at 21:09
    
Just checking: you added/uncommented UseDNS no in sshd_config on the server (not in ssh_config on the client), right? But as ssh localhost shows the same delays, I guess reverse DNS is not the problem. –  Arjan Feb 23 '10 at 9:22
    
The comment is in sshd_config, and the test result with my home PC (Same Windows7 + cygwin version) doesn't have this problem. –  prosseek Feb 25 '10 at 16:06
    
@prosseek, comment? No leading #-character before UseDNS no I hope? –  Arjan Feb 25 '10 at 16:37
show 1 more comment

I've been experiencing slowness on the first case you've mentioned.

debug1: identity file /Users/smcho/.ssh/id_dsa type -1 <---

My OpenSSH version was 5.1. I removed the old installation and installed cygwin OpenSSH 5.5, the speed issus has gone. Maybe you could try this..

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.