Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

13 Answers 13

up vote 67 down vote accepted

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

share|improve this answer
+1 that is the most common cause of delay when logging in to ssh – matthias krull Jul 22 '10 at 9:22
"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
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 '14 at 10:42
+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 '14 at 9:22
@SkippyleGrandGourou: Some Solaris versions were using a modified OpenSSH, called SunSSH, which had some annoying incompatibilities. Solaris 11.3 adds OpenSSH back and SunSSH will eventually be removed... – Gert van den Berg Jan 4 at 13:01

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
Worked for me thanks +1. – racic Jan 12 '15 at 15:02

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

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
  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, the culprit was IPv6 resolution, it was timing out. (Bad DNS setting at my host provider, I guess.) I discovered this by doing ssh -v, which showed which step was hanging.

The solution is to ssh with the -4 option:

ssh -4

share|improve this answer
I suspect more and more of us are going to see this as time passes and things (badly and) slowly accommodate IPV6. Thanks! – sage Feb 3 at 23:13
... and this answer is particularly unhelpful without the debug message that confirms this is the problem. – E.P. Apr 29 at 12:21

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

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

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

With systemd, login may hangs on dbus communication with logind after some upgrades, then you need to restart logind

systemctl restart systemd-logind

Saw that on debian 8, arch linx, and on a suse list

share|improve this answer

This is probably only specific to the Debian/Ubuntu OpenSSH, which includes the user-group-modes.patch written by one of the Debian package maintainers. This patch allows the ~/.ssh files to have the group writable bit set (g+w) if there is only one user with the same gid as that of the file. The patch's secure_permissions() function does this check. One of the phases of the check is to go through each passwd entry using getpwent() and compare the gid of the entry with the gid of the file.

On a system with many entries and/or slow NIS/LDAP authentication, this check will be slow. nscd does not cache getpwent() calls, so every passwd entry will be read over the network if the server is not local. On the system I found this, it added about 4 seconds for each invocation of ssh or login into the system.

The fix is to remove the writable bit on all of the files in ~/.ssh by doing chmod g-w ~/.ssh/*.

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

For me there was an issue in my /etc/hosts file. So ssh was trying two different IP (one wrong) which took forever to time-out.

Using ssh -v did the trick here:

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [] port 22.
debug1: connect to address port 22: Connection timed out
debug1: Connecting to remotesrv [] port 22.
debug1: Connection established.
share|improve this answer

I found that restarting systemd-logind.service only cured the problem for a few hours. Changing UsePAM from yes to no in sshd_config has resulted in fast logins, although motd is no longer displayed. Comments about security issues?

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .