Steven Foerster

Writing

Why is it so slow? Troubleshooting DNS, SSH

A practical workflow for isolating slow SSH sessions by separating DNS, TCP, and authentication latency.

Networking DNS SSH Troubleshooting

Originally published on LinkedIn. Lightly edited for clarity.

When SSH feels slow, the instinct is to blame the network. Sometimes that is correct.

The bigger delays often come from DNS or authentication lookups that block the handshake. The fix is to time each phase and remove the mystery.

Start with a stopwatch

Capture the exact delay before you change anything. A quick baseline tells you whether the issue is name resolution, TCP setup, or authentication:

time ssh -vvv user@host

The debug output will show where the pause happens.

If it stalls before any key exchange, you are likely stuck in DNS. If it stalls after key exchange, you are likely stuck in authentication or reverse lookups.

DNS is the usual suspect

Client-side resolver delays are common, especially with long search domains or unreachable DNS servers.

Test DNS independently from SSH:

time getent hosts host

dig host

Look for:

  • Multiple search suffixes that force repeated queries.
  • IPv6 lookups timing out before falling back to IPv4.
  • Split-horizon DNS that returns private addresses your client cannot reach.

If DNS is slow on the client, SSH will feel slow.

Fix resolver configuration or add a local caching resolver before tuning SSH.

Reverse DNS on the server

SSHD can block on reverse DNS for the connecting IP. That delay is invisible to the client unless you check server logs.

If reverse lookups are not needed, disable them:

  • UseDNS no in sshd_config.

If you do need reverse DNS, make sure forward and reverse records are consistent.

Mismatches cause timeouts and authentication warnings.

GSSAPI and Kerberos lookups

GSSAPI authentication can introduce long pauses when Kerberos is misconfigured.

If you do not use Kerberos, disable it for faster logins:

  • GSSAPIAuthentication no in sshd_config or ~/.ssh/config.

If you do use Kerberos, validate the KDC reachability and ticket cache before blaming SSH.

Network path and MTU issues

TCP handshakes can be slow when there is packet loss, asymmetric routing, or MTU black holes.

Quick checks:

  • ping -M do -s 1472 host to detect MTU issues.
  • mtr to identify loss or jitter.
  • ss -tn to confirm handshake timing.

These are rarer than DNS or auth issues, but they are real in hybrid networks and VPN-heavy setups.

A minimal checklist

  1. Baseline with ssh -vvv and note the pause.
  2. Time getent hosts for the same target name.
  3. Check reverse DNS and UseDNS on the server.
  4. Confirm GSSAPI behavior matches your environment.
  5. Only then start testing MTU or routing anomalies.

Most slow SSH sessions are not mysterious. They are slow name resolution or slow authentication.

Once you isolate the phase, the fix is usually small.

2026 Perspective

The tooling is better, but the root cause pattern has not changed: latency is most often in name resolution or identity lookups.

As systems add more identity checks and private networking layers, these delays are even easier to trigger. A consistent measurement workflow still saves the most time.