How to Fix SSH Connection Hangs: The Complete Diagnostic Guide

Objective

You type your SSH command, press enter, and... nothing. The cursor blinks. Minutes pass. No error message appears, no timeout warning—just an endless wait that leaves you locked out of critical systems. This is one of the most common and frustrating problems system administrators face. SSH connection hangs differ from outright failures because they provide no feedback. When SSH refuses a connection or reports an authentication error, at least you know what went wrong. But a hanging connection could mean dozens of different things: network issues, firewall blocks, DNS timeouts, resource exhaustion, permission problems, or configuration errors.

This guide teaches you to diagnose SSH hangs systematically. Instead of trying random fixes and hoping something works, you'll learn a logical troubleshooting process that identifies the actual problem quickly. Each step builds on the previous one, narrowing down possibilities until you find the root cause.

Step 1: Confirm Basic Network Connectivity

The most fundamental question: can your computer reach the server at all? Many SSH problems aren't SSH problems—they're network problems. Before investigating SSH-specific issues, verify that basic network communication works.

• Test Server Reachability

ping -c 4 192.168.1.100

Replace 192.168.1.100 with your server's IP address. This sends four packets and waits for responses. You'll see response times and packet loss statistics.

• Trace the Network Path

traceroute 192.168.1.100

If ping fails, traceroute shows where packets are being dropped. Each line represents a network hop between your computer and the destination. Timeouts or asterisks indicate problems at specific points.

• Interpreting Results

• • Successful ping, but SSH hangs: The network works, so focus on SSH-specific issues like firewall rules, service configuration, or authentication problems.
  • Ping fails completely: Fix network connectivity first. Check cables, routing tables, and network configuration before troubleshooting SSH.
  • Intermittent ping with packet loss: Network instability exists. This might cause SSH to work sometimes but hang during packet drops.

Step 2: Verify SSH Port Accessibility

Your server might be online, but is the SSH port actually accepting connections? Port 22 could be closed, blocked by a firewall, or SSH might be listening on a different port entirely.

• Test the Default SSH Port

nc -vz 192.168.1.100 22

Netcat (nc) attempts a connection to port 22. The -v flag provides verbose output, and -z closes the connection immediately after checking if the port is open.

• Test Custom Ports

nc -vz 192.168.1.100 2222

If your SSH daemon runs on a non-standard port (common for security), test that specific port instead.

• Alternative Method Using Telnet

telnet 192.168.1.100 22

If netcat isn't installed, telnet works similarly. Press Ctrl+] then type "quit" to exit.

• Understanding Port Test Results

• • "Connection succeeded" or "open": The port is accessible. SSH is listening and your problem lies elsewhere.
  • "Connection refused": The server received your request but nothing is listening on that port. Either SSH isn't running, or it's using a different port.
  • Timeout with no response: A firewall is likely dropping packets silently. This is the most common cause of SSH hangs.

Step 3: Inspect Firewall Configuration

Firewalls that drop SSH packets cause connections to hang indefinitely rather than failing immediately. Unlike a "connection refused" error, dropped packets make clients wait until they timeout—which can take minutes.

Important: You need console access or out-of-band management to check firewall rules. If SSH is your only access method and you're locked out, you'll need physical access or a management interface like iLO, iDRAC, or a cloud provider's console.

• Check Firewalld (RHEL, CentOS, Fedora)

sudo firewall-cmd --list-all

This displays all active zones, services, and ports. Look for "ssh" in the services list or port 22 in the ports list.

• Add SSH to Firewalld

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

The --permanent flag saves the rule across reboots. The reload command applies changes immediately without disrupting existing connections.

• Check Iptables Rules

sudo iptables -L -n -v

On systems using iptables directly, this lists all filtering rules. The -n flag shows IP addresses instead of hostnames (faster), and -v shows packet counts for each rule.

• Check Nftables (Modern Systems)

sudo nft list ruleset

Newer distributions replace iptables with nftables. This command displays the complete filtering ruleset.

• Don't Forget TCP Wrappers

cat /etc/hosts.allow
cat /etc/hosts.deny

TCP Wrappers provide another access control layer that can silently block SSH. If /etc/hosts.deny contains "ALL: ALL" or "sshd: ALL", SSH connections will be rejected.

Step 4: Restart the SSH Daemon

Sometimes the SSH service becomes unresponsive due to bugs, resource exhaustion, or configuration issues. A simple restart often resolves temporary glitches and applies any recent configuration changes.

• Restart SSH on Red Hat-Based Systems

sudo systemctl restart sshd

• Restart SSH on Debian-Based Systems

sudo systemctl restart ssh

Note the different service names: "sshd" on Red Hat family, "ssh" on Debian family.

• Check Service Status

sudo systemctl status sshd

This shows whether the daemon is active, how long it's been running, and recent log entries. Look for error messages or warnings.

• Verify Automatic Startup

sudo systemctl is-enabled sshd

Ensures SSH starts automatically after system reboots. If it returns "disabled", enable it with:

sudo systemctl enable sshd

Step 5: Analyze System Resource Usage

Heavily loaded systems respond slowly or appear to hang when spawning new SSH sessions. High CPU usage, memory exhaustion, or disk I/O bottlenecks all contribute to delayed responses that feel like connection hangs.

• Monitor System Activity in Real-Time

top

Press 'q' to quit. Watch the %CPU and %MEM columns. Processes using 90%+ CPU or consuming most available memory indicate resource problems.

• Check Load Averages

uptime

This displays load averages for the past 1, 5, and 15 minutes. Compare these numbers to your CPU count (from lscpu or /proc/cpuinfo). Load averages higher than your CPU count indicate the system is overloaded.

• Examine Memory Usage

free -h

The -h flag displays sizes in human-readable format (GB, MB). If "available" memory is very low and swap is heavily used, memory pressure is slowing everything down.

• Monitor Disk I/O Performance

iostat -x 1 5

Shows extended disk statistics, updating every second for five iterations. High %util values (near 100%) indicate disk bottlenecks. Watch the await column—high values mean processes are waiting for disk operations.

What to Do About Resource Problems

If system load is abnormally high, identify resource-intensive processes using top or ps aux. Kill unnecessary processes or wait until load decreases before expecting normal SSH performance. SSH needs available CPU and memory to fork new processes and handle authentication.

Step 6: Review SSH Logs Carefully

Log files transform troubleshooting from guesswork into systematic problem-solving. They contain detailed information about connection attempts, authentication failures, and configuration errors that aren't visible to users.

• Server Logs on Red Hat Systems

sudo tail -f /var/log/secure

• Server Logs on Debian Systems

sudo tail -f /var/log/auth.log

The -f flag "follows" the log file, showing new entries as they appear in real-time.

• Using Systemd's Journal

sudo journalctl -u sshd -f

On systemd-based distributions, journalctl provides centralized logging. The -u flag filters for the sshd unit, and -f follows new entries.

• Enable Verbose Client Output

ssh -v user@192.168.1.100

A single -v flag shows basic connection progress: DNS resolution, TCP connection, protocol version exchange, and authentication attempts.

• Maximum Verbosity for Deep Debugging

ssh -vvv user@192.168.1.100

Triple verbose output reveals everything: key exchange algorithms being negotiated, authentication methods attempted, encryption ciphers proposed, and exactly where the connection stalls.

• Reading Verbose Output

Look for lines indicating where the process stops. Common stall points include:

• • "Connecting to..." - Network or routing problem
  • "SSH protocol version exchange" - Firewall or network issue
  • "Key exchange" - Cipher mismatch or performance problem
  • "Authenticating" - Permission or key problems

Step 7: Diagnose DNS Resolution Issues

Reverse DNS lookups cause unexpected delays when the SSH server tries to resolve connecting client IP addresses. If DNS is slow or misconfigured, SSH waits for these lookups to timeout before proceeding—adding seconds or even minutes to connection time.

• • Test Forward DNS Resolution

dig server.example.com

Verifies that hostnames resolve to correct IP addresses. Look at the "ANSWER SECTION" for the result and "Query time" for how long it took.

• Test Reverse DNS Lookup

dig -x 192.168.1.100

Checks if the IP address has a reverse DNS record (PTR record). Slow or missing reverse DNS commonly causes SSH delays.

• Simpler Alternative Testing

host 192.168.1.100

The host command provides quicker, simpler output for basic DNS verification.

• Disable Reverse DNS in SSH

If DNS is problematic, disable reverse lookups entirely. Edit the SSH daemon configuration:

sudo nano /etc/ssh/sshd_config

Find the UseDNS line (or add it if missing):

UseDNS no

Save the file, then restart SSH:

sudo systemctl restart sshd

• Trade-offs

Disabling reverse DNS improves connection speed significantly when DNS is slow or broken. The downside: your logs will show IP addresses instead of hostnames, making them slightly less readable. For most environments, faster connections are worth this trade-off.

Step 8: Fix SSH Key File Permissions

SSH enforces strict security requirements on key files and directories. If permissions are too permissive (allowing other users to read), SSH refuses to use them—sometimes silently causing hangs rather than clear error messages.

• Correct Client-Side Permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 600 ~/.ssh/config

The .ssh directory should be readable only by you (700). Private keys must be accessible only to you (600), never world-readable or group-readable.

• Correct Server-Side Permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

On the server, the authorized_keys file must also be protected. Group or world-readable authorized_keys files are rejected by SSH.

• Fix Ownership Problems

chown -R $USER:$USER ~/.ssh

Ensures your user account owns all SSH files. Files owned by other users cause authentication failures.

• Verify Everything is Correct

ls -la ~/.ssh

Check the output. You should see:

• • drwx------ for the .ssh directory
  • -rw------- for private keys (id_rsa, id_ed25519, etc.)
  • -rw-r--r-- for public keys (id_rsa.pub) - these can be world-readable
  • -rw------- for authorized_keys and config files
• When Permission Problems Occur

These issues commonly appear after:

• • Copying keys from another system
  • Restoring from backups
  • Editing files with sudo (causing root ownership)
  • Cloning home directories between accounts

Step 9: Investigate MTU and Network Path Issues

Maximum Transmission Unit (MTU) mismatches cause packets to be fragmented or silently dropped, leading to slow or hanging connections. This problem appears most commonly with VPNs, tunnels, and complex network paths where different segments have different MTU values.

• Check Current MTU Settings

ip link show

Displays MTU values for all network interfaces. Standard Ethernet uses 1500 bytes. VPNs often use smaller values like 1400 or 1380 due to encapsulation overhead.

• Test MTU with Ping

ping -M do -s 1472 192.168.1.100

The -M do flag prevents fragmentation, and -s 1472 sets the packet size (1500 minus 28 bytes for headers). If this fails, try progressively smaller sizes:

ping -M do -s 1400 192.168.1.100
ping -M do -s 1300 192.168.1.100

The largest successful size indicates the path MTU.

• Temporarily Lower MTU

sudo ip link set dev eth0 mtu 1400

Replace eth0 with your actual interface name (found from ip link show). This change lasts until reboot.

• Make MTU Changes Permanent

Edit your network configuration files. Location varies by distribution:

• • RHEL/CentOS: /etc/sysconfig/network-scripts/ifcfg-eth0
  • Debian/Ubuntu: /etc/network/interfaces or /etc/netplan/*.yaml
  • Modern systems: NetworkManager or systemd-networkd configs
• When MTU Matters

If lowering MTU improves SSH performance, investigate MTU settings on intermediate network devices like routers, VPN concentrators, and firewalls. The entire path needs consistent MTU values to avoid fragmentation issues.

Step 10: Resolve SELinux Context Problems

Security-Enhanced Linux (SELinux) can block SSH access through incorrect file security contexts or policy violations. Unlike firewall blocks that prevent connections entirely, SELinux problems often cause hangs during authentication without generating obvious error messages.

• Check SELinux Status

sestatus

Shows detailed SELinux information: whether it's enforcing, permissive, or disabled, plus loaded policy details.

• Quick Status Check

getenforce

Returns just the current mode: Enforcing, Permissive, or Disabled.

• Search for Access Denials

sudo ausearch -m avc -ts recent

Queries the audit log for Access Vector Cache (AVC) denials from recent time. Look for entries mentioning ssh or sshd.

• Analyze Problems with Helpful Suggestions

sudo sealert -a /var/log/audit/audit.log

Provides human-readable analysis of SELinux problems with specific suggestions for fixing them. This tool is invaluable for understanding what SELinux is actually blocking.

• Restore Correct File Contexts

sudo restorecon -R -v /home/username/.ssh
sudo restorecon -R -v /etc/ssh

Reapplies proper SELinux security contexts to SSH directories. The -R flag works recursively, and -v shows what's being changed.

• Check File Contexts

ls -Z ~/.ssh

The -Z flag displays SELinux contexts. SSH directories should have ssh_home_t contexts.

• Critical Warning

Never disable SELinux as a troubleshooting shortcut. While setting it to permissive temporarily (setenforce 0) can confirm whether SELinux is the problem, always fix the underlying context or policy issue rather than disabling this security layer permanently.

Quick Command Reference

Use this table as a quick lookup when troubleshooting SSH hangs:

Diagnostic Area	Command	What It Reveals
Network connectivity	ping -c 4 SERVER_IP	Basic network reachability and latency
Network path	traceroute SERVER_IP	Where packets are being dropped
Port accessibility	nc -vz SERVER_IP 22	Whether SSH port is open and reachable
Firewall rules	sudo firewall-cmd --list-all	Current firewall configuration
Service status	sudo systemctl status sshd	Whether SSH daemon is running properly
System load	uptime	CPU load averages
Memory usage	free -h	Available memory and swap usage
Disk I/O	iostat -x 1 5	Disk performance bottlenecks
Live logs	sudo journalctl -u sshd -f	Real-time SSH daemon logs
Connection debug	ssh -vvv user@SERVER_IP	Detailed connection process and where it stalls
DNS resolution	dig -x SERVER_IP	Reverse DNS lookup speed and results
File permissions	ls -la ~/.ssh	SSH directory and key file permissions
MTU settings	ip link show	Network interface MTU values
MTU testing	ping -M do -s 1472 SERVER_IP	Maximum unfragmented packet size
SELinux status	sestatus	SELinux enforcement mode and policy
SELinux denials	sudo ausearch -m avc -ts recent	Recent access denials
SELinux repair	sudo restorecon -R -v ~/.ssh	Fixes incorrect security contexts

 

Troubleshooting Workflow Summary

Follow this systematic approach when SSH connections hang:

1. Verify basic connectivity - Can you ping the server?
2. Test the SSH port - Is port 22 (or your custom port) accessible?
3. Check firewalls - Are firewall rules blocking SSH?
4. Restart SSH service - Is the daemon responsive?
5. Examine system resources - Is the server overloaded?
6. Review logs - What do server logs and verbose client output show?
7. Test DNS - Are reverse lookups causing delays?
8. Verify permissions - Are SSH key files properly secured?
9. Check MTU - Are packet size issues causing problems?
10. Investigate SELinux - Are security contexts blocking access?

Each step builds on previous ones. If ping fails, fix network connectivity before investigating SSH-specific issues. If logs show authentication attempts, the problem lies in SSH configuration rather than network access.

Conclusion

SSH connection hangs are frustrating precisely because they provide no immediate feedback about what's wrong. Unlike clear error messages that point to specific problems, a hanging connection could indicate dozens of different issues. This guide provides a systematic framework for diagnosing these problems efficiently. The key to effective troubleshooting isn't memorizing commands, it's understanding why each diagnostic step matters and what it reveals. Network connectivity tests show whether the problem is SSH-specific or network-wide. Verbose SSH output pinpoints exactly where connections stall. Log analysis transforms invisible problems into visible, solvable issues.

With practice, this diagnostic process becomes intuitive. You'll develop instincts about which problems are most likely based on symptoms. A hang during initial connection suggests network or firewall issues. A hang after password prompt points to authentication or permission problems. A hang that resolves after 30 seconds indicates DNS timeout issues. Most importantly, systematic troubleshooting saves time. Rather than trying random fixes and hoping something works, you methodically eliminate possibilities until you identify the root cause. This approach works under pressure, scales to complex environments, and builds genuine expertise rather than just memorized solutions.