I have an Ubuntu 9.04 server. I am facing a long delay while doing SSH to the server. I have added "UseDNS no" in sshd_conf and commented out "GSSAPIAuthentication yes" in ssh_conf, still the problem is there.

On seeing /etc/resolve.conf, it looks like the problem is there.

Contents of /etc/resolve.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
nameserver 10.xx.xx.xx
nameserver 10.xx.xxx.xx
search xyz.com

I read somewhere that multiple nameserver entries here can cause problems. I am using a VPN client on that server to connect to my company's network, and it looks like the entries are automatically added by the vpn client.

How do I fix these long delays without breaking my VPN client/connections. I don't mind not being able to use my companies server names/aliases while connection via VPN from my server, but would like to fix the long SSH delay while connecting to the server.


  1. Yes, I meant /etc/sshd_conf

  2. I am using IP address to connect directly

  3. I am not using VPN to connect to my server (where there is delay). However, a VPN client is running on the server to further connect to some other network. The login FROM my server using the VPN client is fast enough.

  4. Sorry, I didnt understand AddressFamily, inet, and some other comments.

Here are debug logs on client side (with approx. delays):

OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010
debug1: Connecting to ......
debug1: Connection established.
debug1: identity file ..... type -1
debug1: identity file ..... type -1
debug1: identity file ..... type -1
debug1: identity file ..... type -1


debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP


debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

NOW THERE IS 40-50 seconds PAUSE

Then it checks fingerprint etc and connects fast.

  • 2
    You edited your answer to say that you really did edit /etc/sshd_conf. That's fine, but I believe Ubuntu ignores that file. Ubuntu has that file stored in /etc/ssh/ssd_config, and won't use the other file unless you've done something very strange to your system. Oct 15, 2010 at 20:01

6 Answers 6



Just to be sure, you really mean /etc/ssh/sshd_config, not sshd_conf, right? I don't think that sshd_conf or sshd.conf are valid files for OpenSSH on Ubuntu, so editing them will do nothing.

I read somewhere that multiple nameserver entries here can cause problems.

Multiple nameservers in /etc/resolv.conf should not cause any problems, although if the first nameserver on the list is slow, it will affect your system. In fact it's a good practice to list redundant nameservers in /etc/resolv.conf in case one nameserver goes down.

Before you dig too deep, try to determine if this problem is on the client side or the server side.

On the client side, turn on SSH verbose mode. This will tell you the progress of the client connection to the server. If the connection from the client to the server is slow, you might see a delay before lines like "debug1: Connection established." or "debug1: Server accepts key: pkalg ssh-dss blen 435".

On the server side, tail the SSH logs in a separate window and watch the logs. You might want to increase the logging to "VERBOSE".


Don't use sshd_conf. Add the following to /etc/ssh/sshd_config , restart SSH and then let us know what happens.

UseDNS no

Change one thing at a time. If UseDNS doesn't work, then try "GSSAPIAuthentication no".

  • UseDNS no on my bastion host increased connection speed from 10 second avg wait, to < 1sec. thank you!
    – theRemix
    Dec 7, 2016 at 9:07

You should be able to create your own user level config file in ~/.ssh/config

From here you can map the host to the numeric ip and it should bypass the DNS lookup altogether. For example say you want to ssh to "glitch.somewhere.net", in your config file do something like:

Host glitch

  User JP19

You can insert a ton of options here as describe in the ssh_config man page (man ssh_config). The key here is that the "HostName" is actually set to a numeric IP rather than a true hostname. Essentially you're setting up multiple shortcuts. So you can ssh to glitch1, glitch2, goog, ...

One potential gotcha, is to make sure the permissions are set correctly so that ssh doesn't freak out. Also, I'd recommend running ssh in verbose mode (ssh -vvv) to make sure it is hanging where you think it is, but I suspect you're on the right trail.


First questions, are you connecting via IP Addresses to the servers or via Domain names?

Second question, are you able to connect to the servers externally or only through the VPN?

The likely cause of the delay is the VPN and connection speeds, not necessarily the result of an SSH connection.


Could you try AddressFamily inet ? It disables ipv6 which triggers a bug in some old systems (it's in the openssh faq).

Perhaps a bit silly but did you restart the ssh server after making the changes?



I had similar problem logging into CentOS/Fedora servers from my Fedora laptop. When connecting from an external network, the process was quick, with a two, maybe three, second delay before the password prompt came up. However, connecting from the internal network, it would take 10-20 seconds to get to the password prompt.


edit ~/.ssh/config

Host 192.168.0... (your target ip)
GSSAPIAuthentication no
PasswordAuthentication yes
ChallengeResponseAuthentication no
ForwardX11 yes

Make sure that ~/.ssh/config permissions are read-only for group/others, write only for user. (chmod to 644).


A log delay while using SSH could be also caused by blocked processes and/or cron-jobs misconfiguration, so check them also (i.e. crontab -l)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy