How to fix Read from socket failed: Connection reset by peer in SSH

SSHINTERMEDIATEHIGH

This error occurs when the SSH connection is unexpectedly terminated by the remote server during the authentication or communication phase. The server closes the TCP connection without properly completing the SSH protocol handshake, often due to server configuration issues, firewall blocking, or resource constraints.

What this error means

The "Read from socket failed: Connection reset by peer" error indicates that the TCP connection to the SSH server has been abruptly closed. The SSH client was reading data from the network socket when it received a TCP RST (Reset) packet from the remote server, terminating the connection. This happens during the key exchange or authentication phase, before the SSH session is fully established. The "reset by peer" designation means the remote side (the SSH server) is actively closing the connection, not due to a timeout or network outage, but because the server itself is rejecting or terminating the connection. Common scenarios where this occurs: - **Server configuration issues**: The SSH daemon (sshd) has misconfigured settings or is rejecting connections based on security policies - **Authentication failures**: The server rejects the connection after failed authentication attempts (especially with Fail2Ban or similar rate limiting) - **Server resource exhaustion**: The SSH service has reached maximum concurrent connections or available resources - **Firewall or security policies**: Network appliances or host firewalls are actively dropping SSH connections - **SSH key permissions**: Incorrect file permissions on server-side SSH configuration files (.ssh, authorized_keys, etc.) - **Network hardware issues**: Network switches, load balancers, or proxies are resetting idle connections - **Server-side crashes or hangs**: The SSH daemon crashes or becomes unresponsive during the handshake

How to fix "Read from socket failed: Connection reset by peer"

1Verify the SSH daemon is running on the server

Check if the SSH service is actually running. Log into the server via console or remote management (not SSH):

On Linux:

bash

sudo systemctl status ssh
# or on some systems
sudo systemctl status sshd

Check if sshd process exists:

bash

ps aux | grep sshd

If SSH is not running, start it:

bash

sudo systemctl start ssh
sudo systemctl enable ssh  # Enable on boot

If the service shows as crashed or failed:

bash

sudo systemctl restart ssh
sudo systemctl status ssh

Check the SSH daemon logs for crash messages:

bash

sudo journalctl -u ssh -n 50
# or on older systems
sudo tail -50 /var/log/auth.log

2Fix SSH server key permissions and regenerate if needed

SSH server keys must have correct ownership and permissions. Check /etc/ssh:

bash

# Check server keys exist and have content
ls -la /etc/ssh/ssh_host_*key*

# Server keys should look like this (non-zero size):
# -rw------- 1 root root  1704 Jan 15 10:23 ssh_host_rsa_key

If keys are missing or have zero size, regenerate them:

On Debian/Ubuntu:

bash

sudo dpkg-reconfigure openssh-server
# or manually
sudo ssh-keygen -A

On RHEL/CentOS:

bash

sudo systemctl restart sshd
# If still broken:
sudo rm /etc/ssh/ssh_host_*key*
sudo systemctl start sshd

Verify keys are now present with proper permissions:

bash

ls -la /etc/ssh/ssh_host_*key

3Check and fix /etc/ssh/sshd_config permissions

Incorrect permissions on the SSH configuration file will cause the daemon to reject connections:

bash

# Check current permissions
ls -la /etc/ssh/sshd_config

# Should be: -rw-r--r-- (644) or -rw------- (600)
# If not, fix it:
sudo chmod 644 /etc/ssh/sshd_config

Check for syntax errors in the configuration:

bash

sudo sshd -t

If errors are shown, fix them. Common issues:

bash

# View the file and look for issues
sudo cat /etc/ssh/sshd_config | grep -v '^#' | grep -v '^$'

# Common problematic settings:
# - PermitRootLogin no (but you need root to test fixes)
# - AllowUsers restricted to specific users
# - Match blocks with incompatible settings

After fixing any issues, restart SSH:

bash

sudo systemctl restart ssh

4Check and fix ~/.ssh directory permissions on server

Incorrect permissions on the user's ~/.ssh directory or authorized_keys file cause authentication to fail:

bash

# Check permissions (as the SSH user)
ls -la ~/.ssh
ls -la ~/.ssh/authorized_keys

# Should be:
# ~/.ssh directory: drwx------ (700)
# authorized_keys file: -rw------- (600)

# Fix if needed:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verify ownership is correct:

bash

ls -ld ~/.ssh
# Should show the current user as owner, not root

# If wrong owner (from running as root):
sudo chown -R $USER:$USER ~/.ssh

5Check if your IP is banned by Fail2Ban

Fail2Ban automatically bans IPs after repeated failed login attempts:

bash

# Check if Fail2Ban is installed and running
sudo systemctl status fail2ban

# List all banned IPs
sudo fail2ban-client status sshd

# Output looks like:
# Status for the jail: sshd
# |- Filter
# |  |- Currently failed: 0
# |  |- Total failed: 45
# |- Actions
# |  |- Currently banned: 1
# |  |- Total banned: 1
# |- Banned IP list: 203.0.113.5

If your IP is banned, unban it:

bash

# Unban specific IP
sudo fail2ban-client set sshd unbanip 203.0.113.5

# Or flush all bans
sudo fail2ban-client reload sshd

To temporarily disable Fail2Ban for testing:

bash

sudo systemctl stop fail2ban
# Try SSH connection
# Then restart
sudo systemctl start fail2ban

6Verify SSH is listening on the correct port and IP

Confirm the SSH daemon is bound to the correct network interface and port:

bash

# Check what SSH is listening on
sudo ss -tlnp | grep ssh
# or
sudo netstat -tlnp | grep ssh

# Output should show something like:
# LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  processes=(... sshd)

If SSH is not listening on port 22 (or your configured port), check sshd_config:

bash

# Check which ports SSH is configured for
sudo grep -i "^Port" /etc/ssh/sshd_config

# If Port is set to something other than 22, connect using:
ssh -p <port_number> user@hostname

If SSH is listening on 127.0.0.1 only instead of 0.0.0.0:

bash

# Check the ListenAddress setting
sudo grep -i "^ListenAddress" /etc/ssh/sshd_config

# Fix if needed by editing sshd_config:
sudo nano /etc/ssh/sshd_config
# Add or modify:
# ListenAddress 0.0.0.0
# ListenAddress ::

sudo systemctl restart ssh

7Check network connectivity and firewall

Verify the server is reachable and firewall is not blocking SSH:

bash

# From the client, test basic connectivity
ping <server_ip>

# Test if port 22 is open
nc -zv <server_ip> 22
# or
telnet <server_ip> 22

# Check with timeout to distinguish "refused" from "timeout"
timeout 5 bash -c "cat < /dev/null > /dev/tcp/<server_ip>/22"
echo $?  # 0 = success, 1 = timeout/refused

On the server, verify iptables or firewall is not blocking:

bash

# Check iptables rules for port 22
sudo iptables -L -n | grep 22

# Check UFW (if enabled)
sudo ufw status
sudo ufw allow 22/tcp

# Check firewalld (if enabled)
sudo firewall-cmd --list-all | grep 22
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

8Check SSH server logs for detailed error information

Server logs often contain the real reason the connection was reset:

bash

# Enable verbose logging in sshd_config
sudo nano /etc/ssh/sshd_config

# Add or modify:
LogLevel VERBOSE
# Or for maximum detail:
# LogLevel DEBUG3

# Restart SSH
sudo systemctl restart ssh

Then attempt the connection and check logs:

bash

# Most recent errors first
sudo tail -30 /var/log/auth.log
# or on some systems
sudo journalctl -u ssh -n 30

# Search for your client IP:
sudo grep "203.0.113.5" /var/log/auth.log | tail -20

Common log messages and what they mean:
- "Maximum authentication attempts exceeded" - Too many failed password/key tries
- "Invalid user" - Username doesn't exist on server
- "Received disconnect from ... [preauth]" - Client disconnected during authentication
- "sshd[PID]: fatal: read_all: Connection reset by peer" - Server crashed or killed
- "socket: Permission denied" - SELinux or AppArmor policy blocking SSH

9Test with increased verbosity from client side

Get more details about where the connection is failing:

bash

# Maximum verbosity
ssh -vvv user@hostname

# Or even more debug output
ssh -vvvv user@hostname 2>&1 | tee ssh-debug.log

Look for where the output stops. Common failure points:

bash

# Stops here = server not listening or firewall blocking
SSH-2.0-OpenSSH_7.4

# Stops here = server crashed after accepting connection
debug1: Authentications that can continue: ...

# Stops here = authentication rejected without reason
debug1: No more authentication methods to try.

If output stops at "SSH-2.0", the server is not even sending its banner properly - likely crashed or misconfigured.

10Check system resource limits

Resource exhaustion can cause SSH daemon to crash or reject connections:

bash

# Check current limits
ulimit -a
sudo su - -c "ulimit -a"

# Common SSH-related limits:
ulimit -n     # File descriptors
ulimit -u     # Max processes
ulimit -c     # Core file size

# If limits are too low, increase them
# Edit /etc/security/limits.conf:
sudo nano /etc/security/limits.conf

# Add:
*       soft    nofile  4096
*       hard    nofile  65536
*       soft    nproc   2048
*       hard    nproc   16384

Check disk space:

bash

df -h /
# SSH needs space for logs and temporary files

Monitor system load during SSH connection attempts:

bash

# In one terminal, watch system metrics
watch -n 1 'free -h; echo "---"; ps aux | grep sshd'

# In another terminal, try SSH
ssh user@hostname

Advanced notes

Understanding TCP RST packets:

The "Connection reset by peer" message indicates receipt of a TCP RST (Reset) packet. This is different from:
- ECONNREFUSED: Nothing is listening on the port (connection refused)
- ETIMEDOUT: No response at all (timeout)
- EPIPE: Connection was established but closed unexpectedly (broken pipe)

RST means the server explicitly rejected the connection, which requires an active decision by the SSH daemon or host kernel.

SSH daemon stability issues:

If the server resets connections during the key exchange phase specifically:
1. Check if OpenSSL is functioning correctly: openssl speed
2. Verify SSH algorithm support: ssh -Q kex
3. Update OpenSSH: apt update && apt install openssh-server openssh-client

Debugging on systems without SSH access:

If you can't SSH to fix SSH, use console access:
- Physical server console
- IPMI/iLO/DRAC remote management
- Cloud provider web console
- Single-user mode (if you can reboot)

From console, verify:

bash

# Check if sshd is running
ps aux | grep sshd

# Check if listening
netstat -tlnp | grep 22

# Try manually starting with maximum debug
/usr/sbin/sshd -ddd

Distinguishing network hardware issues:

If SSH works with one client but not another:
1. Try from a different network path (different ISP, mobile hotspot, VPN)
2. Test from different ports on the same client
3. Check if specific IPs or subnets are affected
4. Review network monitoring (tcpdump) to see if server sends RST or just ignores packets

Network hardware issues usually show up as random, intermittent failures affecting all clients eventually, not specific to SSH.

SELinux and AppArmor issues:

On systems with mandatory access control, SSH might be blocked by policy:

bash

# Check SELinux status
getenforce

# If enforcing, check for denials
sudo audit2allow -a

# Temporarily disable for testing
sudo setenforce 0
# Try SSH
sudo setenforce 1

# Check AppArmor
sudo aa-status | grep ssh
sudo aa-complain /etc/apparmor.d/usr.sbin.sshd
# Try SSH
sudo aa-enforce /etc/apparmor.d/usr.sbin.sshd

How to fix Read from socket failed: Connection reset by peer in SSH

What this error means

Typical symptoms

Common causes

How to fix "Read from socket failed: Connection reset by peer"

Advanced notes

Related errors

Official resources & further reading