How to fix Connection reset by peer in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 636 views

This error occurs when the SSH server abruptly closes the connection during the key exchange phase, before authentication completes. Common causes include firewall blocks, IP bans, misconfigured SSH service, or network issues.

Quick fix

Fixes Connection reset by peer

ssh -vvv user@server.com
  1. Enable verbose mode to see where connection fails
  2. Verify the SSH server is running on the target host
  3. Confirm network connectivity and port 22 is reachable
  4. Check firewall rules on the server
ssh — error
ssh -vvv user@server.com
Connection reset by peer

What this error means

The 'Connection reset by peer' error, often appearing as 'ssh_exchange_identification: read: Connection reset by peer', means the remote SSH server forcefully terminated the connection before establishing a secure session. During the key exchange (KEX) phase—when the client and server negotiate cryptographic keys—something caused the server to immediately close the TCP connection. The term 'peer' refers to the remote server, and 'reset' means the connection was forcefully terminated rather than gracefully closed. This error occurs very early in the SSH handshake, before username/password authentication even begins.

Typical symptoms

  • SSH connection fails immediately with 'Connection reset by peer' message
  • Error occurs during key exchange phase (before reaching login prompt)
  • ssh -v shows 'Offering public key' followed by connection reset
  • Connection works from some clients but not others
  • Intermittent connection failures from the same client
  • Connection fails consistently from one IP address

Common causes

  1. Firewall or security group blocking SSH port 22 on the server
  2. IP address blocked by Fail2Ban after repeated failed attempts
  3. SSH daemon (sshd) not running or misconfigured on the server
  4. IP listed in /etc/hosts.deny file or TCP wrapper rules denying access
  5. Server SSH configuration limiting simultaneous connections (MaxStartups too low)
  6. Network connectivity issue or high latency causing timeout during key exchange
  7. SSH configuration mismatch (incompatible key exchange algorithms)
  8. Too many SSH keys on client exceeding MaxAuthTries on server
  9. Server running out of memory or other resource exhaustion
  10. Client network/firewall actively resetting outbound SSH connections

How to fix "Connection reset by peer"

1Enable verbose mode to see where connection fails

Run the SSH command with -vvv flag to get detailed diagnostic information about where in the handshake the connection is being reset:

bash
ssh -vvv user@server.com

Look for the last successful step before 'Connection reset by peer' appears. This tells you if it's failing during algorithm negotiation, key exchange, or immediately upon connect.

2Verify the SSH server is running on the target host

From a host with access to the server (console, bastion, etc.), check that sshd is running:

bash
sudo systemctl status ssh
# or
sudo service sshd status

If not running, start it:

bash
sudo systemctl start ssh
sudo systemctl enable ssh  # Enable on boot
3Confirm network connectivity and port 22 is reachable

Test basic connectivity to the server on port 22:

bash
ping server.com
telnet server.com 22
nc -zv server.com 22

All three should succeed. If any fail, you have a network or firewall issue preventing access to port 22.

4Check firewall rules on the server

Verify firewall allows inbound SSH. The method depends on your firewall:

UFW (Ubuntu/Debian):

bash
sudo ufw status
sudo ufw allow 22/tcp

iptables (Linux):

bash
sudo iptables -L -n | grep 22
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

firewalld (RHEL/CentOS):

bash
sudo firewall-cmd --list-all
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload
5Check if your IP is blocked by Fail2Ban

Fail2Ban automatically bans IPs after repeated failed login attempts. From the server, check if your IP is banned:

bash
sudo fail2ban-client status sshd
sudo iptables -L -n | grep <your-ip>

If your IP is listed, unban it:

bash
sudo fail2ban-client set sshd unbanip <your-ip>

Alternatively, temporarily stop Fail2Ban while troubleshooting:

bash
sudo systemctl stop fail2ban
6Verify TCP Wrapper rules allow your IP

Check the /etc/hosts.allow and /etc/hosts.deny files to ensure your IP or hostname isn't blocked:

bash
sudo cat /etc/hosts.deny
sudo cat /etc/hosts.allow

If your IP is in hosts.deny, remove it or comment it out:

bash
sudo nano /etc/hosts.deny
# Remove or comment the line blocking your IP

Then try connecting again.

7Try connecting from a different machine or network

Test SSH from a different client or IP address to isolate whether the issue is client-specific or server-side:

bash
# From a different machine
ssh user@server.com

If connection succeeds from the alternate client, the issue is likely with your original client's network, local firewall, or SSH configuration. If it fails from all clients, the issue is on the server side.

8Check SSH daemon configuration and limits

Review /etc/ssh/sshd_config for settings that might reject your connection:

bash
sudo nano /etc/ssh/sshd_config

Key settings to check:
- MaxStartups 10:30:100 (limit concurrent connections) - try increasing
- AllowUsers or DenyUsers - ensure you're allowed
- PermitRootLogin - if you need root access
- MaxAuthTries 6 - increase if you have many SSH keys

After changes, validate config and restart:

bash
sudo sshd -t
sudo systemctl restart ssh
9Check server system resources

High memory usage or CPU load can cause the SSH daemon to reject connections. From the server:

bash
free -h          # Check memory
df -h            # Check disk
top -b -n 1      # Check CPU and processes

If resources are exhausted, identify and kill memory-hogging processes, or reboot the server. SSH should recover after freeing resources.

bash
sudo reboot
10Check SSH logs on the server

Review the SSH daemon logs to see the actual reason the connection was rejected:

bash
# Most systems
sudo tail -f /var/log/auth.log

# Or on some systems
sudo journalctl -u ssh -f

Look for error messages corresponding to your connection attempt. The logs often reveal the exact reason (auth failure, max sessions, IP blocked, etc.).

Advanced notes

Algorithm Negotiation: If using older SSH clients or servers, algorithm mismatches during key exchange can cause resets. Explicitly specify algorithms on the client if needed:

bash
ssh -oKexAlgorithms=diffie-hellman-group14-sha1 user@server.com

Keepalive Settings: If the connection is established but then reset after a period of inactivity, adjust ClientAliveInterval and ServerAliveInterval:

Client (~/.ssh/config):

bash
Host *
  ServerAliveInterval 60
  ServerAliveCountMax 3

Server (/etc/ssh/sshd_config):

bash
ClientAliveInterval 300
ClientAliveCountMax 2

Multiple SSH Keys: If you have many SSH keys, the client may exceed MaxAuthTries before finding the correct key. Remove unused keys from ~/.ssh or specify a single key:

bash
ssh -i ~/.ssh/specific_key user@server.com

SELinux: On SELinux-enforcing systems, ensure SSH context rules allow connections:

bash
sudo getenforce
sudo semanage port -l | grep ssh

Docker/Container Networking: If connecting to a containerized SSH server, ensure port 22 is properly exposed and the container isn't crashing on startup.

Frequently asked questions

What does "Connection reset by peer" mean?
The 'Connection reset by peer' error, often appearing as 'ssh_exchange_identification: read: Connection reset by peer', means the remote SSH server forcefully terminated the connection before establishing a secure session. During the key exchange (KEX) phase—when the client and server negotiate cryptographic keys—something caused the server to immediately close the TCP connection. The term 'peer' refers to the remote server, and 'reset' means the connection was forcefully terminated rather than gracefully closed.
How do I fix "Connection reset by peer"?
This error occurs when the SSH server abruptly closes the connection during the key exchange phase, before authentication completes. Common causes include firewall blocks, IP bans, misconfigured SSH service, or network issues.
What causes "Connection reset by peer"?
Firewall or security group blocking SSH port 22 on the server IP address blocked by Fail2Ban after repeated failed attempts SSH daemon (sshd) not running or misconfigured on the server
Is the "Connection reset by peer" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading