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 http://www.walkernews.net/2009/04/06/how-to-fix-scp-and-ssh-login-prompt-is-very-slow-in-linux/ 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!
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
icuenvme, you’re wrong. I tried disabling dns lookups first, that didn’t work. Disabling GSS did the trick. Thanks, Nathan!
thanks nathan, I was getting desperate!
You are a scholar and a saint! Perfect fix!!
Well, only the “UseDNS yes” setting worked for me.
Thanks for the tip.
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)
Add “options single-request-reopen” to your resolv.conf file. This should do it without worrying about the other options listed above.
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.
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.
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.
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.
i changed the
GSSAPIAuthentication yes
to
GSSAPIAuthentication no
and delayed ssh login is solved!
Good tip!
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.
” 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.