SSH is slow? Try these proven solutions first

SSH (Secure Shell) is a cornerstone tool for remote server management, but slow connections can severely hinder productivity.

Whether you’re facing delays during connection establishment, authentication, or data transfer, the root causes often fall into predictable categories—network configuration, SSH service settings, server resource constraints, or authentication issues.

This guide walks you through a systematic troubleshooting process to identify and resolve SSH slowness, with actionable steps for different scenarios.

1. Classify the Symptom First

Before diving into technical checks, categorize the slowdown pattern to narrow down the cause. Common symptoms include:

• Slow connection establishment: A long delay (10–30 seconds) after running the ssh command before seeing the password prompt or key authentication request.
• Slow authentication: Delays after entering the password or selecting an SSH key, before gaining shell access.
• Slow data transfer: Lag when typing commands, transferring files via scp/sftp, or running interactive sessions.
• Intermittent slowness: Connections are fast sometimes but slow others, indicating network instability or resource fluctuations.

2. Quick Wins: Fix the Most Common Causes

Most SSH slowdowns stem from misconfigured default settings. Start with these high-impact fixes before moving to complex diagnostics.

2.1 Disable DNS Reverse Resolution

By default, the SSH server performs a reverse DNS lookup on the client’s IP address to verify its hostname. If the DNS server is unresponsive or the IP has no reverse record, this causes significant delays during connection establishment.

Solution:

1. Edit the SSH server configuration file (/etc/ssh/sshd_config):

sudo nano /etc/ssh/sshd_config

1. Find or add the line UseDNS no (comment out any existing UseDNS yes).
2. Restart the SSH service to apply changes:

sudo systemctl restart sshd  # For systemd-based systems (CentOS 7+, Ubuntu 16.04+)
sudo service ssh restart      # For SysVinit systems

2.2 Disable GSSAPI Authentication

GSSAPI (Generic Security Services Application Program Interface) is an authentication framework used for Kerberos environments. For most standalone servers or non-corporate networks, GSSAPI is unnecessary but enabled by default, leading to authentication timeouts.

Solution:

1. In /etc/ssh/sshd_config, set:

GSSAPIAuthentication no

1. Restart the SSH service (as above).
2. Optimize client-side settings (add to ~/.ssh/config on your local machine) to avoid GSSAPI attempts:

  Host *
  GSSAPIAuthentication no
  UseDNS no

3. Troubleshoot Authentication-Related Slowness

If delays occur after entering a password or selecting an SSH key, focus on authentication mechanisms and related system files.

See also: Mastering the Linux Command Line — Your Complete Free Training Guide

3.1 PAM Module Issues

Pluggable Authentication Modules (PAM) handle user authentication for SSH. Misconfigured PAM modules (e.g., LDAP, SSSD) or network-dependent modules can cause slow authentication.

Diagnosis:

# Check PAM configuration for SSH
cat /etc/pam.d/sshd
# Monitor authentication logs in real time
journalctl -fu sshd

Solution:

Temporarily comment out non-essential PAM modules (e.g., pam_sss.so for LDAP) and test connectivity. Re-enable modules one by one to identify the culprit. For non-Kerberos environments, disable PAM entirely (not recommended for password authentication):

# In /etc/ssh/sshd_config
UsePAM no

3.2 Large or Misconfigured authorized_keys Files

For key-based authentication, a large ~/.ssh/authorized_keys file (with hundreds of expired keys) or incorrect permissions forces the SSH server to spend time processing entries or validating file access.

Diagnosis:

# Check file size and number of keys
ls -la ~/.ssh/authorized_keys
wc -l ~/.ssh/authorized_keys
# Verify correct permissions (critical for SSH key authentication)
stat ~/.ssh/authorized_keys

Solution:

• Clean up expired or unused keys to reduce file size.
• Set strict permissions (SSH rejects overly permissive files):

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

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

3.3 Overgrown Log Files

SSH updates /var/log/lastlog and /var/log/wtmp during login to track user sessions. Large or fragmented log files (especially on NFS storage) slow down this process.

Diagnosis:

ls -la /var/log/lastlog /var/log/wtmp
last | wc -l  # Count entries in wtmp

Solution:

• Truncate large files:

cat /dev/null > /var/log/wtmp
# For sparse lastlog files (common in Linux)
cp /var/log/lastlog /var/log/lastlog.bak
> /var/log/lastlog

• Configure logrotate to auto-rotate logs (create /etc/logrotate.d/wtmp):

/var/log/wtmp {
  monthly
  create 0664 root utmp
  minsize 1M
  rotate 1
}

4. Resolve Network-Related Slowness

Network instability, misconfigured MTU, or bandwidth constraints often cause SSH delays—especially during data transfer.

4.1 Test Network Latency and Packet Loss

Use network tools to verify connectivity quality between client and server.

# Continuous ping test (check latency)
ping -i 1 [server_ip] | tee ping.log
# MTR for route analysis (identifies intermediate hop issues)
mtr -r -c 100 [server_ip]
# Capture SSH traffic for deep analysis
tcpdump -i eth0 host [server_ip] and port 22 -w ssh.pcap

Look for high latency (>100ms), packet loss (>1%), or dropped hops—these indicate network bottlenecks.

4.2 Fix MTU Mismatch

MTU (Maximum Transmission Unit) defines the largest packet size transmitted over the network. Mismatched MTU values cause packet fragmentation and retransmissions, slowing SSH.

Diagnosis and Solution:

1. Test optimal MTU with ping (DF = Don’t Fragment):

ping -D -s 1472 [server_ip]

1. If you see “Packet needs to be fragmented but DF set”, reduce the packet size (e.g., 1462, 1452) until the ping succeeds. Add 28 (IP + ICMP headers) to get the optimal MTU.
2. Set MTU on the client (example for macOS/Linux):

# macOS (en0 = network interface)
sudo ifconfig en0 mtu 1400
# Linux (eth0 = network interface)
sudo ip link set dev eth0 mtu 1400

4.3 Optimize SSH Encryption Algorithms

Older encryption algorithms (e.g., aes128-cbc) are slow and insecure. Modern AEAD (Authenticated Encryption with Associated Data) algorithms offer better performance and security.

Solution:

Update /etc/ssh/sshd_config to prioritize fast, secure algorithms:

Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

Restart SSH and verify supported algorithms:

ssh -Q cipher [server_ip]

5. Address Server Resource Constraints

A server under high load (CPU, memory, disk I/O) may struggle to respond to SSH requests in a timely manner.

Diagnosis:

# Check CPU and memory usage
top -bn1 | head -20
free -h
# Check disk I/O
iostat -x 1 5
# Verify SSH daemon status
ps aux | grep sshd
systemctl status sshd

Solution:

• Terminate resource-hungry processes or upgrade server hardware.
• Protect the SSH daemon from being killed by the OOM (Out-of-Memory) killer:

echo -1000 > /proc/$(pgrep -o sshd)/oom_score_adj

• Limit user resource usage via/etc/security/limits.conf.

6. Advanced Troubleshooting Tools

For persistent issues, use these tools to dig deeper into SSH behavior:

• strace: Track system calls made by the SSH daemon to identify bottlenecks:

sudo strace -p $(pgrep sshd) -t -e connect,read,write

• ssh -v: Verbose mode to debug connection and authentication steps:

ssh -vvv user@server_ip  # Triple v for maximum verbosity

• Mosh: Replace SSH for unstable networks (maintains sessions during latency spikes):

sudo yum install mosh  # RHEL/CentOS
sudo apt install mosh  # Debian/Ubuntu
mosh user@server_ip

7. Preventive Measures

Avoid SSH slowness with proactive configuration and maintenance:

1. Apply the above optimizations (UseDNS no, GSSAPIAuthentication no, strong ciphers) to sshd_config by default.
2. Set up log rotation for wtmp and lastlog to prevent file bloat.
3. Use tmux or screen to maintain sessions during disconnections.
4. Monitor server resources and network quality regularly (e.g., with Nagios, Zabbix).
5. Add server IPs to the client’s /etc/hosts file to bypass DNS lookups:

192.168.1.100 server.example.com

Conclusion

SSH slowness is rarely caused by a single factor—start with the most common fixes (disabling DNS reverse resolution and GSSAPI) before moving to network diagnostics and server resource checks.

By following this systematic approach, you can resolve 90% of SSH slowdowns quickly.

For intermittent issues, leverage verbose logging and network analysis tools to uncover hidden bottlenecks. With proactive configuration, you can ensure consistent, fast SSH performance for remote management.