7

When connecting to one specific server (running Debian Lenny) it always takes about 5 seconds before it prompts me to enter a password. After login there is no noticable delay anymore. There is also no delay at any other server in this network (although they are not running Lenny).

Any idea what could be causing this and how to fix it?

5 Answers 5

7

It's most often dns problem. Try setting 'UseDNS no' in sshd_config.

4
  • 6
    Down vote: If you have dns problems, fix them and do not turn the dns capabilities of sshd off. Sep 22, 2010 at 8:55
  • @natxo What am I losing by disabling the DNS functionality? It wasn't working anyway and I did not notice any ill effects.
    – user51326
    Sep 22, 2010 at 9:21
  • why would you want to hide a problem you have? It's like hiding your head in the sand ... Sep 22, 2010 at 11:38
  • 2
    I am having the same problem, and I plan to solve it the same way. If this was a production machine where real dns information was valuable and useful I'd agree, but in my case (can't speak for the question asker here) it's my personal dev box, and it just needs to let me log in. I couldn't care less if the dns lookup worked.
    – Stu
    May 15, 2012 at 18:32
4

It could possibly be a reverse-dns lookup delay. If your connecting host doesn't have an DNS entry, try adding an entry for your source system in /etc/hosts on the server you're connecting to.

2

In addition to 3molos answer you could also make sure that your box has correct DNS servers setup in /etc/resolve.conf, given that you have a DNS server available on the network. This will also prevent the delay,

5
  • The server is in the DMZ and it seems sshd is trying to look up the internal ip address (192.168.*.*) of my connecting client. Those are not listed in the external DNS server the server is using. The internal DNS server is not reachable from the DMZ right now.
    – user51326
    Sep 22, 2010 at 9:20
  • Given the situation I would stick to the 'UseDNS no' solution, its quick and easy. I think that its important though, as natxo pointed out, that one firstly tries to figure out and solve any existing problems, before finding ways around them. An underlying DNS problem could cause more problems later on. Sep 22, 2010 at 9:33
  • if you query a dns server which gives you the 'wrong' ip information back, you would never be able to login the server using a host name, would you? Not unless you have the server name in the host file of your workstation Sep 22, 2010 at 10:04
  • The webserver is seeing the internal ip addresses of our network, which an external dns server obviously cannot resolve. The DNS is not giving back wrong information, it just does not know anything about the 192.168.*.* addresses. The webserver itself has a correct public DNS entry, so everything else works without problems.
    – user51326
    Sep 22, 2010 at 10:23
  • well then, configure your dns server properly. Add another zone for internal use only Sep 22, 2010 at 11:34
1

If your DNS resolution is working fine, then turn the avahi-daemon service off. That will solve your problem.

/etc/init.d/avahi-daemon stop

If it does (I think it will, because we have had the same problem), then you need to turn it off permanently so that the next reboot will not start it again. You can do that with sysv-rc-conf (you need to install it first). You could do it with update-rc.d but the manpage says you should not:

Please note that this program was designed for use in package maintainer scripts and, accordingly, has only the very limited functionality required by such scripts. System administrators are not encouraged to use update-rc.d to manage runlevels. They should edit the links directly or use runlevel editors such as sysv-rc-conf and bum instead.

sysv-rc-conf works a lot like chkconfig for Red Hat based distributions.

If you need to do this at a lot of servers, use a configuration management like cfengine. We have this for our cfengine2 setup:

classes:
debian::
    # if this does not return 0 then ..
    avahi_off = ( !ReturnsZero(/usr/sbin/sysv-rc-conf avahi-daemon) )

shellcommands:
avahi_off::
    # ... deactivate the avahi daemon
    "/usr/sbin/sysv-rc-conf avahi off" inform=true
    "/etc/init.d/avahi... stop" inform=true
1

I have a case where it is not a 5 seconds delay but a 30 seconds delay, as in SSH takes about 30 seconds to connect on my computer. Sadly that question had been marked as duplicated of this. I suspect they maybe different issue.

For my case, CSF was badly setup and it kept restarting /bin/dbus-daemon either case it was using too much memory or been running for too long. There is a known bug where if dbus is restarted and systemd-logind is not, you will see those lines in /var/log/messages

Jan  4 21:02:25 rtw dbus-daemon: dbus[9976]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Jan  4 21:02:25 rtw dbus[9976]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Jan  4 21:02:50 rtw dbus[9976]: [system] Failed to activate service 'org.freedesktop.login1': timed out
Jan  4 21:02:50 rtw dbus-daemon: dbus[9976]: [system] Failed to activate service 'org.freedesktop.login1': timed out

21:02:25 when the SSH connect was first initiated and 21:02:50 when the connection is established. So the wait is equal to the configured time out duration.

you can fix the issue simply by restarting systemd-logind

systemctl restart systemd-logind

For me, on additional step to make sure dbus is whitelisted in CSF/LFD.

You must log in to answer this question.