How to fix Connection reset by peer in SSH

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

ssh -vvv [email protected]

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.

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

sudo systemctl status ssh
# or
sudo service sshd status

If not running, start it:

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

Test basic connectivity to the server on port 22:

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.

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

UFW (Ubuntu/Debian):

sudo ufw status
sudo ufw allow 22/tcp

iptables (Linux):

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

firewalld (RHEL/CentOS):

sudo firewall-cmd --list-all
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload

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

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

If your IP is listed, unban it:

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

Alternatively, temporarily stop Fail2Ban while troubleshooting:

sudo systemctl stop fail2ban

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

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

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

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

Then try connecting again.

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

# From a different machine
ssh [email protected]

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.

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

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:

sudo sshd -t
sudo systemctl restart ssh

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

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.

sudo reboot

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

# 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.).