Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'd love for one of you smart and helpful folks to post a list of common causes of delays during an ssh login. Specifically, there are 2 spots where I see a range from instantaneous to multi-second delays.

  1. Between issuing the ssh command and getting a login prompt and
  2. between entering the passphrase and having the shell load

Now, specifically I'm looking at ssh details only here. Obviously network latency, speed of the hardware and OSes involved, complex login scripts, etc can cause delays. For context I ssh to a vast multitude of linux distributions and some Solaris hosts using mostly Ubuntu, CentOS, and MacOS X as my client systems. Almost all of the time, the ssh server configuration is unchanged from the OS's default settings.

What ssh server configurations should I be interested in? Are there OS/kernel parameters that can be tuned? Login shell tricks? Etc?

share|improve this question
    
are you using local accounts ? - sometimes i find pam authentication can add a delay to logging in with ssh –  Sirex Jul 22 '10 at 7:08
    
Usually local accounts. Sometimes NIS. –  Peter Lyons Jul 24 '10 at 2:39
    
Worth having a look at here: <a href="thegeekstuff.com/2010/07/… Slow: Hanging at SSH2_MSG_SERVICE_ACCEPT received</a>. –  thegeek Jul 24 '10 at 17:15

8 Answers 8

up vote 33 down vote accepted

Try setting UseDNS to no in /etc/sshd_config or /etc/ssh/sshd_config.

share|improve this answer
3  
+1 that is the most common cause of delay when logging in to ssh –  matthias krull Jul 22 '10 at 9:22
1  
"Solaris 11 note: I tried the UseDNS no setting on Solaris 11 and it corrupted the service start. Not exactly a friendly response by the service. YMMV with other *Nix variants but it seems UseDNS no may not be a valid option in Solaris 11." - comment by Keith Hoffman –  Sathya Jan 11 '12 at 7:21
2  
I was skeptical as I use to login using the IP address (home LAN), but this solution fixed my issue. For Google's sake, though it was occurring just after, the delay had nothing to do with the "key: /home/mylogin/.ssh/id_ecdsa ((nil))" message (when running ssh -vvv). –  Skippy le Grand Gourou May 19 at 10:42
1  
+1 for making it explicit, the file /etc/ssh/sshd_config ! I was adding in /etc/sshd_config and seeing no difference at all!! –  vyom Nov 20 at 9:22

When I ran ssh -vvv on a server with a similar slow performance I saw a hang here:

debug1: Next authentication method: gssapi-with-mic

By editing /etc/ssh/ssh_config and commenting out that authentication method I got the login performance back to normal. Here's what I have in my /etc/ssh/ssh_config on the server:

GSSAPIAuthentication no

You can set this globally on the server, so it doesn't accept GSSAPI to authenticate. Just add GSSAPIAuthentication no to /etc/ssh/sshd_config on the server and restart the service.

share|improve this answer
    
I found this to be the case on with my RHEL5 servers once winbind/ad logins were configured. –  Chad Feb 22 '13 at 20:57

You can always start ssh with the -v option which displays what is being done at the moment.

$ ssh -v you@host

With the information you gave I can only suggest some client side configurations:

  • Since you write that you are entering passwords manually, I would suggest that you use public key authentification if possible. This removes you as a speed bottleneck.

  • You could also disable X-forwarding with -x and authentication forwarding with -a (these might already be disabled by default). Especially disabling X-forwarding can give you a big speed improvement if your client needs to start an X-server for the ssh command (e.g. under OS X).

Everything else really depends on what kinds of delays you experience where and when.

share|improve this answer
    
Good hint about verbosity, you can also increase it by having more v's. Up to 3 IIRC. –  vtest Sep 22 '10 at 18:51

Work fine.

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS no do not work with OpenIndiana !!!

Read "man sshd_config" for all the options

"LookupClientHostnames no" if your server can not resolve

share|improve this answer

Besides the DNS issues already mentioned, if you're ssh'ing into a server with many NFS mounts, then there can be a delay between password and prompt as the quota command checks for your usage/quota on all filesystems not mounted with the noquota. On Solaris systems, you can see this in the default /etc/profile and skip it by running touch $HOME/.hushlogin .

share|improve this answer

If none of the above answers works and you're facing dns reverse lookup problems you can also check if nscd (name service cache daemon) is installed and running.

If this is the problem it is because you have no dns cache, and each time you query for a hostname that is not on your hostfile you send the question to your name server instead of looking in your cache

I tried all the above options and the only change that worked was start nscd.

You should also verify the order to make dns query resolution in /etc/nsswitch.conf to use hosts file first.

share|improve this answer

Regarding the 2. point, here is an answer that don't require to modify the server nor require to have root/administrative privileges.

You need to edit your "user ssh_config" file which is:

vi $HOME/.ssh/config

(Note: you would have to create the directory $HOME/.ssh if it does not exist)

And add:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

You can do so on a per host basis if required :) example:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Make sure the IP address match your server IP. One cool advantage is that now ssh will provide autocomplete for this server. So you can type ssh lin + Tab and it should autocomplete to ssh linux-srv.

share|improve this answer

For me I needed GSSAPI, and I didn't want to turn off reverse DNS lookups. That just didn't seem like a good idea, so I checked out the main page for resolv.conf. It turns out that a firewall between me and the servers I was SSHing to, was interfering with DNS requests, because they weren't in a form that the firewall expected. In the end, all I needed to do was add this line to resolv.conf on the servers that I was SSHing to:

options single-request-reopen

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.