What's Actually Happening

"Connection reset by peer" means the TCP connection was forcibly closed by the remote end. Unlike a timeout (silence) or refusal (rejection), a reset is an abrupt termination mid-handshake or mid-session.

The Error You'll See

bash
$ ssh user@server.example.com
ssh: connect to host server.example.com port 22: Connection reset by peer

Or during an active session:

bash
$ ssh user@server.example.com
user@server:~$
client_loop: send disconnect: Connection reset by peer

Why This Happens

  1. 1.Server SSH daemon crashed or restarted - The process handling your connection died
  2. 2.Load balancer or proxy dropped the connection - Intermediate network device closed it
  3. 3.MTU/fragmentation issues - Large packets being dropped causing TCP reset
  4. 4.Server ran out of resources - Memory/CPU exhaustion killed sshd
  5. 5.TCP Wrappers (/etc/hosts.deny) - Connection allowed then denied mid-handshake

Step 1: Check sshd Status on the Server

```bash # Check if sshd is running sudo systemctl status sshd

# Check for recent restarts or crashes sudo journalctl -u sshd --since "1 hour ago" | tail -50 ```

Look for crashes, OOM kills, or restarts:

bash
Apr 03 10:15:23 server systemd[1]: sshd.service: Main process exited, code=killed, status=9/KILL
Apr 03 10:15:23 server systemd[1]: sshd.service: Failed with result 'signal'.

Step 2: Check System Resources

```bash # Check memory free -h

# Check for OOM kills sudo dmesg | grep -i "out of memory|oom"

# Check current load uptime ```

If the server ran out of memory, the OOM killer may have terminated sshd.

Step 3: Check TCP Wrappers

bash
# Check if TCP wrappers is blocking
cat /etc/hosts.deny
cat /etc/hosts.allow

If you see sshd: ALL or similar in hosts.deny, connections are being rejected after initial TCP handshake.

Step 4: Check for MTU Issues

```bash # Check MTU settings ip link show | grep mtu

# Try connecting with smaller MTU ssh -o "MTUDiscovery=no" user@server.example.com ```

MTU problems often show as "connection reset" during large data transfers.

Step 5: Check Intermediate Network Devices

If there's a load balancer, firewall, or proxy between you and the server:

  1. 1.Check load balancer health checks and timeouts
  2. 2.Check firewall connection tracking table limits
  3. 3.Check for any IDS/IPS that might be resetting connections

Step 6: Check Cloud Provider Limits

For cloud servers:

  • AWS: Check Security Groups, NACLs, and connection tracking
  • Azure: Check NSG flow logs for dropped packets
  • GCP: Check VPC firewall rules

Verify the Fix

```bash ssh -v user@server.example.com

# Should see clean connection: debug1: Connecting to server.example.com port 22. debug1: Connection established. debug1: Remote protocol version 2.0 ```