Ever had your SSH session disconnect right in the middle of a production deployment?
I have.
After getting burned by it a few times, I created a simple troubleshooting checklist that helps me quickly find the root cause.
You're in the middle of a critical deployment or debugging session on a production server.
Suddenly:
Connection to 172.20.10.5 closed by remote host.
You reconnect… and it happens again 5 minutes later.
If this sounds familiar, you're not alone. SSH disconnections are one of the most frustrating issues for developers and DevOps engineers.
Here's the exact checklist I use to diagnose and fix recurring SSH disconnect problems.
1. Check Network Connectivity First
ping <server-ip>
traceroute <server-ip>
mtr <server-ip> # Great for intermittent network issues
Look for:
- Packet loss
- High latency
- Unstable VPN connections
- ISP connectivity issues
Sometimes the problem isn't the server at all.
2. Check Server Resource Usage
Overloaded servers often become unresponsive and can drop SSH sessions.
top
htop
free -h
uptime
Pay special attention to:
- High load average
- Very low available memory
- OOM (Out Of Memory) Killer activity
- CPU saturation
3. Check SSH Logs
SSH logs often tell you exactly why the connection was terminated.
Ubuntu/Debian
sudo tail -f /var/log/auth.log
RHEL/CentOS/Rocky
sudo tail -f /var/log/secure
Modern systems
sudo journalctl -u sshd -f
Look for:
- Timeout messages
- Authentication failures
- SSH daemon restarts
- Connection errors
4. Fix SSH Timeout Settings (Server Side)
Edit the SSH daemon configuration:
sudo nano /etc/ssh/sshd_config
Add or modify:
ClientAliveInterval 300
ClientAliveCountMax 3
This means:
- Send a keepalive packet every 300 seconds.
- Disconnect only after 3 failed responses.
Restart SSH:
sudo systemctl restart sshd
5. Configure Client-Side Keepalive
Create or edit:
nano ~/.ssh/config
Add:
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
This helps prevent many idle SSH disconnections.
6. Check Firewalls, VPNs & Load Balancers
Some common culprits:
- Firewall idle timeouts
- Cloud load balancer timeouts
- VPN session timeouts
- NAT session expiration
Always troubleshoot the entire network path, not just the server.
7. Use tmux or screen (A Life Saver)
tmux
# Do your work
Ctrl + B then D # Detach
tmux attach # Reconnect later
This is a must-have habit for anyone working on Linux servers.
Even if your SSH session disconnects, your processes keep running.
8. Check System Limits
ulimit -a
cat /etc/security/limits.conf
Low limits can sometimes cause unexpected connection issues under heavy load.
Bonus Tip: Enable SSH Debugging
If the issue is difficult to reproduce:
ssh -vvv user@server-ip
The verbose output often reveals:
- Authentication issues
- Timeout problems
- Network interruptions
- Key exchange failures
A Real Production Incident
During a late-night deployment, our SSH sessions kept disconnecting every 3–4 minutes.
We initially suspected the server itself. CPU and memory looked fine, and SSH logs showed nothing unusual.
The actual culprit?
A firewall between our workstation and the server had an aggressive idle timeout configured.
Increasing the timeout and enabling SSH keepalives fixed the issue completely.
That incident taught me an important lesson:
Don't just troubleshoot the server. Troubleshoot the entire path between your machine and the server.
My SSH Troubleshooting Flow
SSH Keeps Disconnecting
↓
1. Network (ping/mtr)
↓
2. Server Resources (top/free)
↓
3. SSH Logs
↓
4. Timeout Settings (Server + Client)
↓
5. Firewall / LB / VPN
↓
6. Use tmux (always)
Final Thoughts
Most SSH disconnections usually come down to:
- Idle timeout settings
- Unstable network connections
- Resource exhaustion
- Firewall or VPN timeouts
- Missing keepalive configuration
One final tip: I never perform deployments directly in a normal SSH session anymore.
Everything runs inside tmux.
Even if my connection drops, my work keeps running.
Have you ever faced a strange SSH disconnect issue? I'd love to hear your experience in the comments.
