Delayed SSH login on CentOS 6

I’ve setup several CentOS 6 virtual machines recently and they all have the same delayed SSH login problem. I’ve found a solution to this problem and I’m documenting it here so I can find it next time!

I originally found this fix at and it’s not specific to CentOS 6, but I’ve only observed this delay problem on CentOS 6.

Now, on to the problem. SSH logins to these CentOS 6 servers were delayed by about 30 seconds. (I never timed it exactly, but it was long enough to be very frustrating when you’re trying to get work done) When logging in using ssh -vvv user@hostname the debug output shows the delay happens at these lines:

debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied

The solution appears to be disabling the GSS API authentication method on the SSH server.

To disable GSS API, first open/etc/ssh/sshd_config in your favorite editor
vim /etc/ssh/sshd_config
Then find the line that says
GSSAPIAuthentication yes
Change it to
GSSAPIAuthentication no
and save the file. Finally, restart the sshd service.
service sshd restart

SSH logins should now be quick as usual!

UPDATE 9/6/2013:
I received an email about this article earlier this year, which goes into more detail of the issues. I’ve added the relevant part of the email below, with permission. Thanks to Martin Brassard for the nice writeup!

Okay this is old, but I think it could have a little clarification for
the options. Those that used useDNS have totally different issue than
what is solved by GSSAPIAuthentication. When you log using SSH, the
server does multiple operations.

One of it is to try to reverse resolve your IP to fetch your hostname.
Why? Developer knows, but I strongly suspect host specific
configuration (i.e hosts.deny). So if your server is unable to reach
the DNS server (for any reason), the ssh daemon tries to reverse
lookup and wait until it times out (~30 seconds). The useDNS yes
(which is also the default behavior if commented) controls this
behavior. If set to useDNS no, then the reverse lookup doesn’t occur
and the IP is used. BEWARE: This is like patching an intense bleeding.
If this is your issue, then your DNS/network configuration is probably
wrong and should be repaired, not patched. Use the useDNS only for
server that shouldn’t/doesn’t have a DNS.

The GSSAPIAuthentication is a totally different issue. This flag tells
SSH to use a GSSAPI server to validate the authentication (from my
understanding). As for the DNS issue, if you do not have such a
server, it will wait until time out before processing further (~30
secondes). The GSSAPIAuthentication is the flag that controls this
behavior. Contrary to the useDNS flag, the GSSAPIAuthentication is
defaulted to no. Commenting it out will prevent the server from trying
to reach that server.

So both have the same symptoms ~30 login delay) caused by the same
reason (server connection time out) but they do NOT try to reach the
same server. To determine which one is required for you, do as the
article states (ssh -vvv ) and look where it froze. If the issue is
the DNS, you will see something like this:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/id_rsa (0x7f0d392ced60)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))

While if the issue is GSS, you will see something like this:

debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic

BEWARE: you can have both at the same time and totally kill your login
time (2 times ~30 seconds).

Hope this clears it for those who don’t have the network knowledge
required to troubleshoot by themselves but still want to understand
what’s going under the hood.

14 thoughts on “Delayed SSH login on CentOS 6

  1. there’s no delayed problem, it’s more like strong security.

    your tutorial it’s almost good, it’s just that it needs one more thing.

    You have to modify: “UseDNS yes” to “UseDNS no” and that’s it.
    cheers mate

  2. icuenvme, you’re wrong. I tried disabling dns lookups first, that didn’t work. Disabling GSS did the trick. Thanks, Nathan!

  3. cm, you’re wrong. I tried disabling GSS and it did nothing. I switched it back on and disabled UseDNS, which did the trick. Thanks, icuenvme (and Nathan for original post)

  4. Add “options single-request-reopen” to your resolv.conf file. This should do it without worrying about the other options listed above.

  5. I had a similar problem connecting from a freshly instaled CentOS 5.8 box to a CentOS 6.2 server. I suspected that the problem was on the client side because the CentOS 5.8 box was the only one unable to connect. Thanks to the clues I’ve found here, my solution was to set GSSAPIAuthentication to ‘no’ in the client’s ssh_config file. Works like a charm. Thank you all. 🙂

  6. Centos 6.2 – had the same issue, and also tried to toggle UseDNS inside of sshd_config without any luck. The timeout was about 30 seconds every time, and I was pulling my hair out, as hostname -f was good, and all other DNS services around it seemed to be responding correctly.

    Once I disabled GSIAuth inside of sshd_config, ssh connections responded as they normally will. Not too sure about GSIauth at the moment, so I will do a bit of research to find why it doesn’t seem to work on vanilla installs of centos 6.2 and ssh.

  7. Thank you your tip helped me. I tried to put usedns=no and the problem was still on. With GSSAPIAuthentication = no there are no delay.

  8. I’m running CentOS 6.3 (64-bit), and OpenSSH 5.4p1.

    Prior to reading this article (nice and clear, short and professional, thank you!) I had tried each combination of changing “UseDNS no” under sshd_config and/or appending “options single-request-reopen” to /etc/resolv.conf.

    None of those three combinations worked, but disabling GSS did it immediately. I wonder if the difference in user’s experiences above could be due to the combination of Centos/RHEL version and OpenSSH version?

    Thanks very much to you for publishing your solution; would have taken me days (if at all) to get around to logging and trying that fix.

  9. i changed the
    GSSAPIAuthentication yes
    GSSAPIAuthentication no

    and delayed ssh login is solved!
    Good tip!

  10. Thanks to the commenters, and of course the blogger.
    On a CentOS 6.3, disabling the DNS lookup solved that for me. The GSSAPI didn’t.

  11. ” GSSAPIAuthentication no ” worked for me, also. I am curious the reason others are fixed with DNS change. Could it be the system’s name servers are not working correctly? If that is true shutting down the DNS resolution would make ssh work faster. Then later when the admin corrects nameserver issues… Well, they would never go back to turn that on and check.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.