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 Linux server running from my house, with a DynDNS URL setup pointing to my public IP address.

One of the things I've noticed is using the remote address such as url.dyn-dns.tv or my public IP connects faster to the server compared to my local 192.168.xx.xx.

Anyone have any ideas why this might be?

share|improve this question
    
why the bounty? do you want to say that the issue is not DNS, or do you just want to have more info why missing DNS reverse lookup can make SSH slow? –  mihi Sep 6 '12 at 19:50
    
Bounty because I wanted some more information on it. Not saying it wasn't DNS just the original answer(s) didn't describe it in detail and I was curious if there were any fixes. –  Grant Sep 7 '12 at 5:04
    
What's your default route/gateway? Is it different from your Linux server? Then it could be related to your ARP Cache. –  artistoex Sep 7 '12 at 12:50
    
Which ethernet/layer 2-devices are involved? How are they connected with each other? Maybe this phenomenon can't be explained in layer 3/4/7 matters alone. –  artistoex Sep 7 '12 at 12:54
    
If it is dns, there are two fixes: Set up reverse DNS for your LAN IPs or disable logging of reverse DNS on the server :D (or tell your provider to disable reverse DNS for your public IP, then both ways will be slow...) –  mihi Sep 7 '12 at 17:25
show 1 more comment

3 Answers

up vote 8 down vote accepted
+50

tl;dr Fix the DNS resolver configuration on the server. (a workaround is to turn off reverse lookups in SSHD but it is better to fix what is broken)


Original answer

Anyone have any ideas why this might be?

Not really but here's an anecdote that might help:

In the past, with a different protocol, when a connection takes unusually long to be established I have found that one cause is DNS timeouts as the server tries to lookup the name of an IP-address so it can record the client name in it's logs. If your client IP-address isn't properly known to the local DNS service and DNS isn't properly configured then the server can wait a long time for DNS to time-out.

The way to look for this sort of effect is to run network sniffers, initially at the client but also at the server, then you may be able to see some network traffic related to the connection, that takes a long time to get a response, or which gets no response (you may see retries)

tcpdump and wireshark are good.


Update 1

At the client with the delay in connecting

  • find the client's IP address

    • On Windows, open a command prompt window and type ipconfig
    • On Linux, open a terminal window and type ifconfig -a
  • optionally confirm you can speedily look up the server's IP-address

    • on windows nslookup servername
    • on Linux dig servername or host servername if your don't have dig.

At the server

  • look up the name of the client
    • check in /etc/resolv.conf for the address of the first DNS nameserver
    • type dig -x 192.168.n.m @nameserver or host 192.168.n.m server where 192.168.n.m is replaced by the actual IP-address of the client and nameserver is the IP-address of the nameserver.
    • repeat for other nameservers listed in /etc/resolv.conf

the server should get a response in milliseconds. With a broken DNS config it will take several seconds to time out.

good config

# time host 192.168.3.4
Host 4.3.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

real    0m0.130s
user    0m0.000s
sys     0m0.020s

bad config

# echo nameserver 1.2.3.4 > /etc/resolv.conf
# time host 192.168.3.4
;; connection timed out; no servers could be reached

real    0m10.010s
user    0m0.000s
sys     0m0.010s

Note the 10 second delay. That means any SSH service that wants to have client names in it's logs will take 10s to set up a SSH connection.


Update 2

It turns out this Q is (probably) an exact duplicate of Why does the "password" prompt take forever when I SSH into my Ubuntu 9.05 server?


Solution

Fix the DNS resolver configuration on the server.

share|improve this answer
    
It's almost certainly a DNS issue. The remote IP has valid DNS. The inside IP does not. –  David Schwartz Aug 31 '12 at 14:40
    
A DNS problem would mean no connection at all, while the problem is slow connection. –  harrymc Sep 6 '12 at 17:12
    
@harrymc: I used to administer DNS for a Fortune-100 company. I've used network analyzers on problems with this symptom. This really happens. The client can lookup the IP-address of the server, the server is waiting to find out the name of the client from the client's IP-address just for logging purposes. –  RedGrittyBrick Sep 6 '12 at 19:11
    
Interesting info, thanks. –  harrymc Sep 6 '12 at 19:31
add comment

I am going to guess that you are not running a local DNS so when the ssh server attempts to do a reverse DNS lookup it is waiting for a timeout. When you are connecting to the external address your are being NATted through an IP address that passes the DNS muster.

To turn off reverse DNS lookups you will have to edit your sshd_config file and find the line "UseDNS" and set it to "no". (You'll have to restart sshd for it to take effect.) Alternatively you can setup your own DNS server for your local subnet. (DNSMasq is a good lightweight one to play with if you don't want to mess with BIND)

share|improve this answer
add comment

You might try calling ssh with the maximal verbose option : ssh -v -v -v.
This might give some useful information.

One explanation I can think of is if your server is listening on iPv4 but you still have iPv6 enabled on your local system. The wait time would then be when ssh is trying in vain to access the server on iPv6, then gives up and tries iPv4 with success.

In any case, I suggest to verify which network adapters are enabled and disable the ones that are useless.

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.