Articles

Fix SSH Read Connection Reset by Peer Error (2026)

April 6, 2026 5 min read

The read: Connection reset by peer error in SSH means the remote server abruptly closed the connection. This isn’t a graceful shutdown; it’s like the server just hung up the phone mid-conversation because something on its end failed or decided it didn’t want to talk anymore.

Here’s why it’s happening, from most to least common:

1. Network Interruption or Firewall Timeout

  • Diagnosis: Run mtr --report <your_server_ip> from your local machine. Look for packet loss or significant latency increases as you get closer to the server. Also, check your local network (e.g., Wi-Fi stability) and any intermediate firewalls (corporate, cloud security groups) for idle connection timeouts. Many firewalls will drop connections that haven’t seen traffic for a specific period, often 300 seconds (5 minutes).
  • Fix:
    • Client-side: Add ServerAliveInterval 60 to your ~/.ssh/config file for the specific host. This tells your SSH client to send a "keep-alive" packet to the server every 60 seconds, preventing intermediate firewalls from timing out.
    • Server-side (if you control it): Add ClientAliveInterval 60 and ClientAliveCountMax 3 to /etc/ssh/sshd_config. This makes the SSH server send keep-alives to the client. Restart the SSH service: sudo systemctl restart sshd.
  • Why it works: These AliveInterval settings ensure there’s always a small amount of traffic flowing, keeping the connection from being marked as idle and dropped by network devices.

2. SSH Server Resource Exhaustion

  • Diagnosis: On the server, check system resource usage.
    • top or htop: Look for high CPU or memory usage.
    • dmesg -T: Check kernel messages for OOM (Out Of Memory) killer events, which might have killed the sshd process.
    • sudo journalctl -u sshd --since "5 minutes ago": Look for any errors related to sshd itself.
  • Fix:
    • Identify the culprit: If a specific process is hogging resources, optimize or kill it.
    • Increase resources: If it’s a persistent issue, you might need to upgrade your server’s RAM, CPU, or disk I/O.
    • Limit SSH connections: In /etc/ssh/sshd_config, you can set MaxSessions 10 and MaxStartups 10:30:100 to limit the number of concurrent sessions and new connection attempts. Restart sshd after changes.
  • Why it works: When a server is overloaded, the operating system might terminate processes (like sshd) to free up resources, leading to the connection being reset. Limiting connections prevents the server from being swamped.

3. SSH Daemon (sshd) Crash or Restart

  • Diagnosis: On the server, check the sshd service status and logs.
    • sudo systemctl status sshd: See if the service is running or recently failed.
    • sudo journalctl -u sshd: Review sshd logs for any unhandled exceptions or crash reports.
  • Fix: If sshd crashed, it’s likely due to a bug or a configuration error.
    • Check configuration: Validate your /etc/ssh/sshd_config for syntax errors: sudo sshd -t.
    • Update SSH: Ensure you’re running a recent, stable version of OpenSSH.
    • Restart the service: sudo systemctl restart sshd. If it keeps crashing, investigate specific error messages in the logs.
  • Why it works: A crashed sshd process cannot handle active connections, so the client receives a "reset" when it tries to communicate. Restarting or fixing the sshd service allows it to properly manage connections.

4. SSH Protocol Mismatch or Malformed Packet

  • Diagnosis: This is less common with standard clients and servers. It can occur if you’re using non-standard SSH options, custom crypto, or if a very specific, malformed packet is sent. Check sshd logs on the server for messages indicating protocol errors or invalid packet formats.
    • sudo journalctl -u sshd | grep -i "protocol\|packet"
  • Fix:
    • Use standard configurations: Ensure both client and server are using widely supported cipher suites and algorithms. Avoid obscure or deprecated options in ~/.ssh/config or /etc/ssh/sshd_config.
    • Update SSH clients/servers: Ensure you’re not mixing very old clients with very new servers or vice-versa, as this can sometimes expose compatibility issues.
    • Disable specific algorithms (as a last resort): In /etc/ssh/sshd_config, you might try explicitly disabling less common algorithms like Ciphers, MACs, KexAlgorithms if logs point to issues with them. Restart sshd.
  • Why it works: The SSH protocol is strict. If either side receives something it doesn’t understand or that violates the protocol, it will often terminate the connection to prevent potential security issues or instability.

5. Server Reboot or Shutdown

  • Diagnosis: If you can’t connect at all, or the error is intermittent and coincides with other services becoming unavailable, the server itself might be rebooting or shutting down. Check monitoring systems or try pinging the server’s IP address.
  • Fix: This isn’t an SSH-specific fix. You need to address why the server is rebooting/shutting down. Check system logs (/var/log/syslog, journalctl) for unexpected shutdowns or kernel panics. Ensure scheduled tasks or system updates aren’t causing unintended reboots.
  • Why it works: When a server shuts down, all running processes, including sshd, are terminated. Any active connections are then broken, resulting in the "reset by peer" error for the client.

6. TCP Wrappers or iptables Blocking

  • Diagnosis: Check /etc/hosts.allow and /etc/hosts.deny on the server to ensure SSH access isn’t being blocked. Also, examine iptables rules: sudo iptables -L -n -v. Look for rules that might be dropping packets to port 22 or resetting connections based on IP address, interface, or state.
  • Fix:
    • hosts.allow / hosts.deny: Ensure you have a line like sshd: ALL in /etc/hosts.allow if you use hosts.deny to block others, or ensure your specific IP is allowed.
    • iptables: Add an explicit rule to allow SSH traffic if it’s being blocked: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT. If you suspect stateful inspection is causing issues, ensure established connections are allowed: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT. Be very careful when modifying iptables.
  • Why it works: These security mechanisms can actively block or reset TCP connections based on configured rules. Correcting or adding rules ensures legitimate SSH traffic is permitted.

The next error you might see after resolving these is related to authentication failures, like Permission denied (publickey,password).

More Deep Dives in Ssh

Want structured learning?

Take the full Ssh course →