Fix Slow SSH Login on Your VPS: UseDNS & GSSAPI

You type ssh root@your-server, hit Enter, and then... nothing. Ten seconds. Twenty. Eventually the password prompt shows up, and once you're in, the shell is perfectly fast. If that sounds familiar, the delay isn't your internet or your VPS CPU. It's SSH waiting on something it doesn't actually need.

Let's find what it's waiting on and stop it.

Symptom: slow before the password prompt, fast after

The key detail is where the pause happens. Commands inside the session run instantly, but the login itself drags. That points at the authentication phase, not at bandwidth or load.

• A 10–30 second pause before the password or key prompt appears.
• The delay happens on every new connection, not just the first.
• Other services on the same VPS (web, mail) respond normally.

If the session itself is laggy, typing feels delayed, or the connection freezes, that's a different problem (packet loss or a saturated network), and you should check ping and mtr instead.

Find the culprit with verbose output

Don't guess. Run the client in verbose mode and watch where it stalls:

ssh -vvv root@your-server-ip

Look at the last line printed before the pause:

Cause 1: UseDNS does a reverse lookup on your IP

When UseDNS yes is set, sshd tries to resolve the hostname of every connecting IP and then checks that the name resolves back to the same address. If the server's DNS resolver is slow or broken, each login waits for the timeout. Home and mobile connections usually have no useful reverse DNS, so the lookup fails slowly.

Open the server config:

sudo nano /etc/ssh/sshd_config

Find or add this line:

UseDNS no

Newer OpenSSH versions already default to no, but older images and some templates still ship with it enabled. Check what's actually active rather than trusting the file:

sudo sshd -T | grep -i usedns

Cause 2: GSSAPI authentication waits for Kerberos

Your client may try GSSAPI (Kerberos) before password or key auth. If you don't run a Kerberos realm, it still tries to contact a KDC, and that can stall until it times out. Turn it off on the server:

GSSAPIAuthentication no

You can also skip it per connection from the client, which is handy if you can't touch the server config yet:

ssh -o GSSAPIAuthentication=no root@your-server-ip

To make it permanent on your own machine, add this to ~/.ssh/config:

Host *
    GSSAPIAuthentication no

Cause 3: A broken resolver on the VPS

If UseDNS was the trigger, the real root cause is often that the VPS can't resolve names quickly. Test it directly:

time getent hosts google.com
cat /etc/resolv.conf

If that takes several seconds, or resolv.conf points at a nameserver that doesn't answer, fix it. On Ubuntu with netplan, set working resolvers (for example 1.1.1.1 and 8.8.8.8) under nameservers: and run sudo netplan apply. A broken resolver also slows down apt, mail delivery and cron jobs, so it's worth fixing properly rather than only turning off UseDNS.

Cause 4: Too many keys offered, or PAM

If you have a lot of keys loaded in your SSH agent, the client offers each one, and the server may drop you after a few failed attempts or slow down. Force it to use only the key you mean:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 root@your-server-ip

On the server side, a heavy PAM stack (like an LDAP or pam_systemd hang) can add delay after authentication succeeds. If the pause happens after you enter the password, check journalctl -u ssh (or sshd on AlmaLinux/Rocky) and /var/log/auth.log or /var/log/secure for the timing.

Apply the fix safely

Never restart sshd blindly on a remote box. Validate the config first and keep your current session open until you've tested a second one:

1. Edit /etc/ssh/sshd_config with the changes above.
2. Run sudo sshd -t. No output means the syntax is fine.
3. Reload: sudo systemctl reload ssh (Ubuntu/Debian) or sudo systemctl reload sshd (AlmaLinux/Rocky).
4. Open a second terminal and log in. Time it with time ssh root@your-server-ip exit.
5. Only close the first session once the new one works.

If you do lock yourself out, the VPS console in your SkyServer panel gets you back in without SSH.

Prevention

• Set UseDNS no and GSSAPIAuthentication no on every new VPS as part of your first-hour setup.
• Keep at least two working resolvers in your network config.
• Use a short ~/.ssh/config entry per server with IdentityFile and IdentitiesOnly yes.
• If you use fail2ban or key-only login, make sure your own IP isn't being rate-limited by an old ban.

Frequently Asked Questions

Is it safe to turn off UseDNS?

Yes, for most setups. The only thing you lose is hostname-based matching in rules like AllowUsers user@host.example.com or from= patterns. If you filter by IP address instead, nothing changes.

Why is SSH slow only from my home connection?

Residential and mobile IPs often have missing or slow reverse DNS records. The server waits for that lookup to fail. Setting UseDNS no removes the wait entirely.

Will these changes affect SFTP and rsync?

They'll make them start faster, since both use the same SSH login. Transfer speed after connecting isn't affected.

The delay happens after I type my password. Is that the same problem?

Not usually. That's more often PAM, a slow home directory mount, or a heavy login script like a long .bashrc. Check the auth logs and try ssh -T root@your-server-ip to compare timing.