Upon connecting to one of my Ubuntu webservers over Secure Shell, I found the connection was taking a long time to establish. At least that was what I thought. It was easy for my to blame my ISP, but since Web and FTP processes were quick, I didn’t take much time to look into or track down the cause of the SSH delays. One evening while installing new packages and frequently re-connecting to the server, I got tired of the delays and found that the issue was not a bandwidth or connection issue at all, but hat upon connection the server was performing a reverse lookup which took approximately 10 seconds. Various sources on the net advised to disable the reverse DNS lookups and the OpenSSH FAQ agrees.
According to the OpenSSH FAQ at www.openssh.org/faq.html, long connection delays (over 10 seconds) are caused by long DNS lookups and can be resolved by specifying the AddressFamily or UseDNS options.
Disabling reverse lookups worked simply by reconfiguring OpenSSHd with the UseDNS no in sshd_config. Doing so has resolved the issue with the delayed connections completely.
I recently ran into a similar problem with one of my FTP hosts. They are running ProFTPd v1.2.10. When I connect to the host, the connection is established but there’s a 10-12 second delay before the server issues the 220 response (Sever ready).
They insist that the issue is a bandwidth/networking issue, and not a server configuration issue. I have tested the connection from my home PC, a remote shell account and my work PC, and the delay remains consistent regardless of which connection I use. Here’s some information I found about ProFTP.
The ProFTP FAQ states that issues could be caused by the server performing various lookups upon connection.
“Normally, incoming active mode data connections and outgoing passive mode data connections have a reverse DNS lookup performed on the remote host’s IP address. In a chroot environment (such as or DefaultRoot), the /etc/hosts file cannot be checked and the only possible resolution is via DNS. If for some reason, DNS is not available or improperly configured this can result in proftpd blocking (“stalling”) until the libc resolver code times out. Disabling this directive prevents proftpd from attempting to reverse-lookup data connection IP addresses“
The server appears to have chroot enabled as I can not browse beyond my personally allocated space on the server. This is one possibility as to what could be causing the issue. Disabling the reverse lookups is as simple as entering changing useReverseDNS on in the configuration file (/etc/proftpd.conf) to useReverseDNS off.
Searching the Internet for related issues also revealed that similar delays are caused when the server is configured to accept authentication via an Ident server. In ProFTPD version 1.3.3rc1, the default was changed from ‘on’ to ‘off’. According to ProFTPd.org:
“The RFC1413 IDENT lookup adds latency to the login process, so much so that it is a FAQ to configure IdentLookups off”. In addition, the IDENT protocol is not secure; it can easily be spoofed using man-in-the-middle attacks.“
The host has skirted around advising me if either of these options were enabled. My personal opinion is the technical support group may not have server-level access and eventually an admin on the server end will go through the same research I have and identify the cause. Should the issue be something else, I will follow up this post with new findings.