Fix a slow SSH connection

We'll run ssh -v to find the delay, disable GSSAPI and DNS lookups, and tune connection options—or point you to network fixes.

Category
Troubleshooting · Servers & Linux
Time
10–20 min
Last reviewed
What you'll need
  • SSH access to the server
  • sudo on the server (for sshd_config)

Step-by-step diagnostic

Step 1 of 7
Show full guide

Steps

Goal: Find the delay with ssh -v, then disable GSSAPI, DNS, or tune for network.

  • Run ssh -v user@host to see where time is spent.
  • Good: You see a pause before “Offering public key” (GSSAPI), at connection start (DNS), or during the session (network). Proceed to Run ssh -v first.
  • Bad: Run ssh -vv for more detail.

Run ssh -v first

Goal: Identify the bottleneck.

  • Run ssh -v user@host. Watch for long pauses.
  • Pause before “Offering public key”: GSSAPI is trying authentication—disable it.
  • Pause at connection start: reverse DNS lookup on the server (UseDNS).
  • Pause during session: network latency—check ping and consider Compression.
  • Good: Bottleneck identified. Proceed to Disable GSSAPI and DNS.
  • Bad: Compare time ssh user@host exit vs time ssh user@ip exit. If IP is faster, DNS adds delay.

Disable GSSAPI and DNS

Goal: Remove GSSAPI and DNS delays.

  • Client: Add to ~/.ssh/config:
    Host *
      GSSAPIAuthentication no
      GSSAPIKeyExchange no
  • Server: Edit /etc/ssh/sshd_config. Add or set UseDNS no. Run sudo systemctl restart sshd (or ssh).
  • For slow links: Add Compression yes to ~/.ssh/config.
  • Good: GSSAPI and UseDNS disabled. Reconnect and confirm faster.
  • Bad: If delay persists, check network—see fix-modem-will-not-connect or fix-firewall-blocks-ssh.

Add connection reuse (optional)

Goal: Reuse a single connection for multiple sessions.

  • Create ~/.ssh/sockets. Add to ~/.ssh/config:
    Host *
      ControlMaster auto
      ControlPath ~/.ssh/sockets/%r@%h-%p
      ControlPersist 600
  • First login opens the connection. Subsequent logins reuse it and are instant.
  • Good: Multiple sessions share one connection.
  • Bad: Not applicable if the delay is on first connection only.

When to escalate

Escalate if:

  • You cannot change sshd_config (managed servers).
  • The delay is purely network latency (high ping).
  • The fix requires firewall or modem changes.

Provide ssh -v output.

Verification

  • ssh user@host reaches the prompt in under a few seconds (after GSSAPI and UseDNS disabled).
  • No long pause before “Offering public key”.
  • time ssh user@host exit shows reduced connection time.

Escalation ladder

Work from the device outward. Stop when the problem is fixed.

  1. ssh -v Run ssh -v to identify the bottleneck.
  2. Disable GSSAPI GSSAPIAuthentication no, GSSAPIKeyExchange no in ~/.ssh/config.
  3. Disable UseDNS UseDNS no in sshd_config; restart sshd.
  4. Compression and ControlMaster Add compression and connection reuse.
  5. Escalate Network or managed server; provide ssh -v output.

What to capture if you need help

Before calling support or posting for help, have these ready. It speeds everything up.

  • ssh -v output (especially around the delay)
  • ~/.ssh/config contents
  • sshd_config UseDNS and GSSAPI settings
  • Steps already tried

Where does ssh -v show the delay?

Run ssh -v user@host. Watch for pauses.

Run `ssh -v user@host`. Pause before "Offering public key": GSSAPI—disable it. Pause at connection start: UseDNS or DNS lookup. Pause during session: network latency. Confirm you should see the bottleneck.

You can change your answer later.

Run ssh -vv

Run `ssh -vv user@host` for more detail. Check the last line before the long pause. GSSAPI, DNS, or network.

Is the delay before key auth (GSSAPI)?

GSSAPI attempts add 5–30 seconds before falling back to keys.

Yes: Add to ~/.ssh/config: Host * GSSAPIAuthentication no GSSAPIKeyExchange no. No: Check UseDNS on server.

You can change your answer later.

Disable GSSAPI

Add to ~/.ssh/config: GSSAPIAuthentication no, GSSAPIKeyExchange no. Reconnect. Confirm you should see faster auth.

Is the delay from DNS or reverse DNS?

Compare ssh user@host vs ssh user@ip. If IP is faster, DNS adds delay.

Yes: On server set UseDNS no in /etc/ssh/sshd_config. Restart sshd. No: Check network—ping host, see fix-modem-will-not-connect.

You can change your answer later.

Disable UseDNS

Edit /etc/ssh/sshd_config. Add UseDNS no. sudo systemctl restart sshd. Confirm you should see faster connection.

Network latency?

Run ping host. High latency or packet loss causes slow SSH. See fix-modem-will-not-connect or fix-firewall-blocks-ssh. Add Compression yes for slow links.

Reviewed by Blackbox Atlas

Frequently asked questions

Why is SSH slow to connect?
GSSAPI authentication attempts, reverse DNS lookup on the server, or slow network. Run ssh -v to see where the delay occurs.
Can I fix slow SSH myself?
Yes. Disable GSSAPIAuthentication and GSSAPIKeyExchange on the client. Set UseDNS no on the server. Add compression for slow links.
When should I escalate slow SSH?
If the delay is network latency, firewall, or modem-related. Or if you cannot change sshd_config (managed servers).

Rate this guide

Was this helpful?

Thanks for your feedback.

Continue to