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!

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:

debug1: SSH2_MSG_SERVICE_REQUEST sent
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.