I have VMware Workstation and after some time I started to notice, that after inserting username ( during ssh connection ) it takes longer and longer to prompt for password. I installed Ubuntu Server 10.10 on this VM.

My VM is located on my local PC.

Does anyone know what might cause that?


SSH does a reverse lookup to resolve the connecting host, the delay you encounter is either due to slow response or more likely a time out.

If you cannot perform reverse resolution from that host, you can alternatively disable the reverse lookup of sshd in the configuration file sshd_config. Look for and change the following entry:

UseDNS no

  • That string wasn't there so I added it to the end of file and restarted ssh. Also might the static ip of my local PC make it faster or it dosen't matter? UPD: After the change it works super fast. – Eugene Aug 8 '11 at 19:49

Yes. It is a misconfigured DNS installation. You need to make sure that the DNS resolution works.

SSH tries to get the rDNS entry from the host that connects to the server. If it can't be resolved you run into a timeout.

  • How could I fix this problem if it is possible at all? – Eugene Aug 8 '11 at 19:21
  • That depends on your setup. Make sure that your local PC is registered at your home router for example. Then configure your router as the DNS server in your VM. If the router has no DNS ability then you have to edit /etc/hosts manually. (It's worth a new question: "How to setup DNS at home?" Which would be transfered to superuser.com. – mailq Aug 8 '11 at 19:29

As others have said, this is likely a DNS resolution problem.

For future reference, note that the OpenSSH FAQ describes this problem under '3.3 - ssh(1) takes a long time to connect or log in'. There are a few other possible causes, but DNS resolution is the most common issue:

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.

Some admins set UseDNS no as a protection against DNS Spoofing. For example, see the book SSH, the Secure Shell, 2nd Edition, section ' TCP/IP settings' by O'Reilly, which says:

We also disable reverse DNS lookups on incoming connections:

# OpenSSH
UseDNS no

You might think security is increased by reverse DNS lookups, but in fact, DNS isn’t secure enough to guarantee accurate lookups. Also, due to other issues in your Unix and network environment, reverse DNS mappings might not even work properly []. Finally, SSH connections can be tremendously slowed down or fail altogether if the client's DNS is hosed (e.g., lots of nameservers, all unresponsive, so sshd times out). The IP addresses of connecting hosts end up in your logs anyway, so you can look them up later.

  • It's just odd, that after I installed Ubuntu Server on my VM it worked perfectly fine and only after some time it started to slow down the ssh connection. – Eugene Aug 9 '11 at 5:32

This is most-likely a reverse DNS lookup. As a quick fix, you can place an entry in the /etc/hosts file of the server you're connecting to with the IP address of your source server.

Also see: 10 second SSH delay prior to successful login

Since this is your local PC and a VM, log into the VM via ssh and type w to display your "FROM" IP/hostname. If it displays an IP instead of a hostname, create an entry in /etc/hosts with that particular IP and give it a representative name. That should work well.

  • Actually this column was empty. – Eugene Aug 8 '11 at 20:06

In addition to what's been posted as answers already, it could simply be a resource problem on the host. What's the resource utilization look like when you get the long delay?

Your Answer

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

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