SSH & SCP Slow Login Fix

SSH & SCP Slow Login Fix

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


On fresh installed Linux servers you might have encountered that it takes quite some time before you get to see the
password prompt when you connect using SSH. 
As soon as you entered the password everything is lightning fast.
There are two items that might cause this problem:

    DNS Resolving
    Authentication methods that are not supported.

---------------------
DNS Resolving
---------------------

The DNS problem is easy to fix, make sure the SSH server is able to resolve DNS queries by configuring a DNS server.
Here’s how to do it on a CentOS server:

[root@server ~]# vim /etc/resolv.conf

And add the following lines:

nameserver 8.8.8.8
nameserver 8.8.8.8

I’m using the DNS servers from OpenDNS, use any server you like. This will allow your server to perform DNS lookups.
You can also tell SSH to disable DNS lookups like this:

[root@server ~]# vim /etc/ssh/sshd_config

And change the “UseDNS yes” field to “UseDNS no”.

This will ensure that SSH doesn’t try to do any reverse lookups.
Don’t forget to restart SSH! If your SSH connection time is still slow after these changes, read on…





---------------------
Authentication
---------------------

SSH supports a number of authentication methods besides username/password.
Let me show you what is happening behind the scenes when you are waiting for the password prompt:

deven@host ~ $ ssh -v root@192.168.1.100

I’m going to connect to a SSH server but I’ll use the “v” parameter (verbose). Here’s what you will see:

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Trying private key: /home/host/.ssh/id_rsa
debug1: Trying private key: /home/host/.ssh/id_dsa
debug1: Trying private key: /home/host/.ssh/id_ecdsa
debug1: Next authentication method: password


Before it shows you the password prompt, SSH will first try to connect using GSSAPI-KEYEX, GSSAPI-WITH-MIC and Public Key.
Since I’m not using these it’s causing a delay when trying to connect to SSH.
Especially the GSSAPI-WITH-MIC is taking a long time…let’s disable it:

[root@server ~]# vim /etc/ssh/sshd_config

Now change the “GSSAPIAuthentication yes” line to “GSSAPIAuthentication no”.



Restart SSH and try to connect again:

deven@host ~ $ssh -v root@192.168.1.100

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/renemolenaar/.ssh/id_rsa
debug1: Trying private key: /home/renemolenaar/.ssh/id_dsa
debug1: Trying private key: /home/renemolenaar/.ssh/id_ecdsa
debug1: Next authentication method: password




With GSSAPI disabled it’s flying!

In case you are wondering, GSSAPI stands for Generic Security Services API and is a standard interface so SSH can communicate with Kerberos.