SSH Establishing Connection Stuck: 6 Causes and the Right Fix

Q: Can I tell if the server is even getting my connection?

On the server: `sudo tcpdump -i any port 22` while attempting to connect. The team that sees the SYN packet has reached the server; the team that doesn't has a network/firewall issue before the server.

Q: What about connection multiplexing issues?

If using `ControlMaster auto` in ssh-config and the master is stuck, new connections to the same host hang. Fix: `ssh -O exit user@server` or remove the control socket (`~/.ssh/controlmaster-*`).

Q: Is there a timeout option?

Yes - `ssh -o ConnectTimeout=10 user@server` gives up after 10 seconds. Useful for scripts that shouldn't hang forever.

SSH establishing connection stuck (no ‘password:’ prompt, no error, just hangs) usually means the TCP connection succeeded but the SSH handshake is hung. Common causes: reverse DNS lookup timing out (UseDNS yes), GSSAPI authentication hanging, MTU mismatch with fragments, firewall on the server blocking the response, or wrong host key. The team that uses ssh -vvv to find the hang point resolves it in under five minutes.

First: identify where it hangs
Cause 1: Reverse DNS timeout
Cause 2: GSSAPI authentication
Cause 3: MTU / fragmentation
Cause 4: Firewall on the server
Cause 5: Host key mismatch
Cause 6: Wrong protocol version or cipher
FAQ

First: identify where it hangs

ssh -vvv user@server

The verbose output shows every step:

debug1: Connecting to server [203.0.113.42] port 22. - DNS resolution.
debug1: Connection established. - TCP connected.
debug1: identity file ... type 3 - key loading.
debug1: Local version string SSH-2.0-OpenSSH_8.9 - protocol negotiation.
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9 - server response.
debug1: kex: algorithm: ... - key exchange.
debug1: SSH2_MSG_KEXINIT sent / received - kex messages.

If it hangs at step 1-2: DNS or network. If step 3-4: client-side key issue. If step 5-7: server-side issue (often UseDNS).

Cause 1: Reverse DNS timeout

SSH by default does a reverse DNS lookup on the client IP (sshd_config -> UseDNS yes). If the client’s PTR record is missing or the DNS server is slow, the lookup times out (5+ seconds).

Fix on the server:

# /etc/ssh/sshd_config
UseDNS no

Then sudo systemctl reload sshd.

The team that sees ‘Connection established’ but no further activity for 5+ seconds has this issue.

Cause 2: GSSAPI authentication

GSSAPI (Kerberos) authentication can hang if the client tries it and the server doesn’t support it.

Fix on the client:

# ~/.ssh/config
Host *
    GSSAPIAuthentication no

Or for one connection:

ssh -o GSSAPIAuthentication=no user@server

The team that sees ‘GSSAPIAuthentication’ lines in -vvv output has this issue.

Cause 3: MTU / fragmentation

If the SSH handshake packets are larger than the path MTU, they fragment or get dropped.

Test:

# Try with smaller packet size
ssh -o IPQoS=lowdelay throughput user@server

Or check MTU:

ip route show
# Look for 'mtu 1500' or similar

The team that sees a VPN or tunnel in the path often has MTU issues. Lower the MTU on the tunnel interface.

Cause 4: Firewall on the server

The TCP connection succeeded (port 22 is open) but something blocks the SSH handshake.

Server-side check:

sudo iptables -L -n -v
sudo ufw status verbose

Look for rules that allow port 22 inbound but block the established connection or related traffic. Stateful firewalls should allow RELATED/ESTABLISHED; if not, the response is blocked.

The team that has iptables with overly strict rules has this issue. Fix: allow related/established traffic.

Cause 5: Host key mismatch

If known_hosts has a stale entry for this server:

ssh-keygen -R server.example.com

Removes the old entry. The next connection prompts for verification.

The team that has rebuilt the server or got a new IP has this issue.

Cause 6: Wrong protocol version or cipher

Very old or very new clients/servers may not negotiate.

Force a specific protocol or algorithms:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@oldserver

The team that connects to old Cisco switches, old OpenSSH, or experimental builds has this issue.

FAQ

How long should an SSH handshake take?

Sub-second on a LAN. Over internet: 100-500ms. Over 1-2 seconds for a healthy connection. The team that sees 5-10+ seconds before any prompt has one of the issues in this post.

Why does SSH hang for 30 seconds then connect?

Classic reverse DNS timeout. The server waits for PTR record lookup, times out, then proceeds. Fix: UseDNS no on the server.

Can I tell if the server is even getting my connection?

On the server: sudo tcpdump -i any port 22 while attempting to connect. The team that sees the SYN packet has reached the server; the team that doesn’t has a network/firewall issue before the server.

What about connection multiplexing issues?

If using ControlMaster auto in ssh-config and the master is stuck, new connections to the same host hang. Fix: ssh -O exit user@server or remove the control socket (~/.ssh/controlmaster-*).

Is there a timeout option?

Yes - ssh -o ConnectTimeout=10 user@server gives up after 10 seconds. Useful for scripts that shouldn’t hang forever.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: