Login via SSH is slow

Most of us have, at some time, experienced slow logins when connecting to a server via ssh. If you poke around you’ll discover that there are plenty of recommendations for addressing the issue. For most people the solutions fix their problem. And then there’s the sneaky one that made me say, “Oh, of course.”

1. Set UseDNS to “no” on the server to which you are connecting
This server-side flag tells the ssh daemon to do reverse-IP lookup before allowing the connection. If it struggles finding one or there isn’t one, it will time out and eventually connect. By default UseDNS is set to “yes”. Changing it to “no” and bouncing the ssh daemon will fix that.
For many people, this fixes it right away.
Setting, on server side, in /etc/ssh/sshd_config: UseDNS no
Restart ssh daemon on server after changing.

2. Set GSSAPIAuthentication to “no” on the client
The GSS API serves primarily to allow authentication via Kerberos. If that’s not something you need to use, make sure it’s off.
You can set it in /etc/ssh/ssh_config on most Linux distros. A line containing “GSSAPIAuthentication no” will do the trick. You may also want to verify it’s not set in ~/.ssh/config.
Setting, on client side, in /etc/ssh/ssh_config: GSSAPIAuthentication no
No restarts required

3. Disable the use of IPv6
I remember way back in the late 90s everyone saying we were in danger of running out of IP address space and needed to start planning to move to IPv6. It was not quite as urgent as Y2K, but it seemed pretty important. Things rocked on for a few years and they sounded the warnings again in the early aughts (early 2000s) – if we don’t move everything, and soon, we’ll be in trouble.
Well, here we are approaching 2020 and lots of things still run on IPv4. Still, a lot of folks enable IPv6 in their stuff by default. And that’s fine, but not everything does. And the things that do may also still use IPv4.
So how does that slow down ssh connections? Good question.
When I was troubleshooting this on a MacBook Pro ssh client, I ran “ssh -vvvv some_host” and noticed it was pausing on “resolving host” for several seconds. This was after I had put the destination IP/host combo in /etc/hosts and disabled UseDNS on the server side. I could ping the host by name with no delay in resolution. So why would ssh hang resolving the host name to an IP address? Then, like the baseball that kept getting bigger and bigger, it hit me. Maybe it was resolving IPv6 (after all, it’s on by default in just about every IP stack out there today).
So, what’s the flag to manipulate it? Is it “EnableIPv6“? Nah – too easy. It’s “AddressFamily“, which is set to “any” by default. When I set it to “inet”, my ssh session connected almost instantaneously.
You can also run ssh with the “-4” option on the fly; e.g. “ssh -4 some_host”
Setting: on client side, in /etc/ssh/ssh_config: AddressFamily inet
No restarts required.

To wrap this up, let me remind you that “ssh -vvvv” is a very helpful troubleshooting tool. Also, never stop just because the common answers don’t fix your problem. Keep digging til you get it sorted out.