How to fix Server unexpectedly closed network connection in SSH

Add keepalive settings to your SSH client configuration to prevent the server from timing out idle connections.

Option A: Add to ~/.ssh/config (persistent)

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Option B: Use command-line flag (one-time)

ssh -o ServerAliveInterval=60 user@host

These settings tell your client to send a keepalive packet every 60 seconds and allow up to 3 unanswered packets before giving up (total ~180 seconds). Adjust the interval based on your timeout (use half your observed timeout value).

If you have access to the server, verify the sshd keepalive settings.

sudo nano /etc/ssh/sshd_config

Look for or add these lines:

ClientAliveInterval 60
ClientAliveCountMax 3
TCPKeepAlive yes

Save and restart sshd:

sudo systemctl restart sshd
# or on some systems:
sudo service sshd restart

ClientAliveInterval tells the server to send keepalive messages every 60 seconds. ClientAliveCountMax allows 3 unanswered messages before closing.

Incorrect file permissions can cause the server to reject your connection after initial authentication.

# On your LOCAL machine
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

# On the SERVER
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Check server logs for permission errors:

sudo tail -f /var/log/auth.log | grep sshd

If many clients are connecting simultaneously, the server may reject new connections.

sudo nano /etc/ssh/sshd_config

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

MaxStartups 10:30:100

The format is start:rate:full. Default (10:30:100) means:
- Reject all connections once 100 unauthenticated connections exist
- Start rejecting at 10 connections with 30% probability increasing linearly

For high-concurrency scenarios, increase these values:

MaxStartups 100:30:500

Restart sshd after changes:

sudo systemctl restart sshd

Enable verbose output to see exactly where the connection closes.

Client-side diagnosis:

ssh -vvv user@host

The output will show each step. Look for:
- debug1: Sending SSH2_MSG_CHANNEL_REQUEST followed by disconnect = likely server timeout
- Connection closed by remote host = server intentionally closed
- Broken pipe = network failure between client and server

Server-side diagnosis:

sudo tail -100 /var/log/auth.log | grep sshd
# or on macOS:
sudo log stream --predicate 'process == "sshd"'

Look for messages like:
- Timeout, client not responding = keepalive timeout
- Connection reset by peer = network issue
- Authentication timeout = client took too long to authenticate

Rule out firewall and network issues.

Check if firewall is closing idle connections:

# Establish SSH connection, then let it idle for 10 minutes
# If it drops, your firewall likely has an idle timeout

# Test from a different network (mobile hotspot, different ISP) to isolate the issue

Monitor connection with tcpdump (advanced):

sudo tcpdump -i any -n 'tcp and host <server_ip> and port 22' -vv

If you see no traffic during idle periods, the client isn't sending keepalives. If you see keepalives being sent but then an RST (reset) from the server/firewall, it's a timeout issue.

For corporate/public networks:
If behind a restrictive firewall, ask network admins about:
- TCP connection idle timeout
- Maximum concurrent connections limit
- SSH traffic filtering or inspection

You may need to use shorter keepalive intervals (30 seconds instead of 60).