3

If I directly connect to Server A, using public key auth from my computer, it takes <0.5 s. But if run the same ssh command from Server B (to connect to Server A) it freezes for about 15 s at the following line : (complete log)

debug2: ssh_connect: needpriv 0

Since I can ssh normally, I assume it is a configuration issue in Server B.

Also, I've tried sshing from B to A, using another account (with password auth). It too hangs at the same line for the same amount. This leads me to believe that it is system ssh config issue, so I'm posting my /etc/ssh/ssh_config as well.

I ran a diff of my ssh_config vs Server B's. The result gave no dissimilarities.

Both Server A and B are running Lucid.

Nemo
  • 9,460

2 Answers2

3

Could be a DNS problem. Do you still get the delay if you use the IP adress instead of the host name?

Florian Diesch
  • 87,389
  • what is the DNS problem? DNS lookup works immediately with other tools (e.g. ping). i'd rather resolve the DNS issue than use the IP address all the time. – Jayen Apr 23 '15 at 04:20
  • Not all tools use the same host lookups. If all is well and you only look up hosts in files and DNS, they go through /etc/nsswitch.conf, then /etc/host.conf, then /etc/hosts, then if not found there, DNS. On my Ubuntu 14.04, ping and ssh both do this. Make sure you test with the same hostname. Also, check if your ~/.ssh/config doesn't have any aliases defined that affect your test. – Reinier Post Nov 25 '16 at 12:52
2

DNS could be the cause most likely.

To verify if it's stemmed from DNS resolution, try to disable DNS verification by putting the following into /etc/ssh/sshd_config on your server:

UseDNS No
kasperd
  • 1,729
daisy
  • 6,582
  • Why does the server need to use DNS? – Jayen Apr 23 '15 at 04:21
  • @Jayen It does not really need DNS. But by default it will perform reverse DNS on the client's IP address followed by forward DNS on the resulting hostname, and if the results do not match, it will write POSSIBLE BREAK-IN ATTEMPT in the log. And those log statements are confusing and hardly ever useful, so I put UseDNS No in the configuration on every server I administrate. – kasperd Nov 25 '16 at 07:18
  • while that makes sense, that doesn't match the accepted answer indicating a DNS issue on the client. – Jayen Nov 25 '16 at 08:58
  • @Jayen The description of the symptoms is not detailed enough to identify whether the problem is on the client or server side. In the past I have seen problems consistent with the symptoms described in the question where the root cause turned out to be a DNS issue on the server side, and specifying UseDNS No would help. So this answer is good advice, even if it turns out it wasn't the reason in the particular scenario. – kasperd Nov 25 '16 at 20:09