How to fix ssh_exchange_identification: read: Connection reset by peer in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 342 views

The SSH client receives a connection reset error during the key exchange phase when attempting to establish an SSH connection. This typically indicates a network issue, firewall blocking, or SSH server misconfiguration.

Quick fix

Fixes ssh_exchange_identification: read: Connection reset by peer

ssh -vvv user@hostname
  1. Enable SSH verbose mode to diagnose the issue
  2. Verify network connectivity to the SSH server
  3. Check if SSH server is running on the remote machine
  4. Check if your IP is blocked by the server
ssh — error
ssh -vvv user@hostname
ssh_exchange_identification: read: Connection reset by peer

What this error means

The error "ssh_exchange_identification: read: Connection reset by peer" occurs when the SSH server abruptly terminates the connection during the identification and key exchange phase of the SSH handshake. The "Connection reset by peer" message means the server unexpectedly closed the TCP connection before completing the SSH protocol handshake. Unlike a "connection timeout" error where the connection simply hangs, this error indicates the server actively rejected or dropped the connection. The error happens very early in the SSH negotiation process, before any authentication occurs. This is a network or configuration-level issue that happens before the client even submits credentials.

Typical symptoms

  • SSH commands fail immediately with 'read: Connection reset by peer'
  • Able to ping the server but SSH connections fail
  • SSH works from some machines or networks but not others
  • The error appears quickly (not a timeout - connection is actively reset)
  • Works intermittently, suggesting intermittent network or service issues

Common causes

  1. A firewall (local, remote, or intermediate network) is blocking or dropping SSH traffic on port 22
  2. The SSH server is not running or has crashed on the remote machine
  3. SSH daemon is configured to reject connections (MaxStartups exceeded, AllowUsers restrictions, etc.)
  4. Your IP address is blocked by security tools like fail2ban, DenyHosts, or TCP wrappers (/etc/hosts.deny)
  5. Network instability causing packet loss or high latency during the key exchange
  6. SSH service configuration error in sshd_config (bad permissions, syntax error, etc.)
  7. Your client IP is listed in /etc/hosts.deny or not in /etc/hosts.allow on the server

How to fix "ssh_exchange_identification: read: Connection reset by peer"

1Enable SSH verbose mode to diagnose the issue

Run SSH with verbose flags (-v, -vv, or -vvv) to see detailed diagnostic information about where the connection fails:

bash
ssh -vvv user@hostname

This will show the exact stage where the connection resets (key exchange, negotiation, etc.) which helps identify the cause.

2Verify network connectivity to the SSH server

Confirm the remote host is reachable on the network:

bash
ping hostname

Also test with a port scanner to verify port 22 is accessible:

bash
nc -zv hostname 22
# or
telnet hostname 22

If ping works but port 22 is unreachable, the issue is almost certainly a firewall.

3Check if SSH server is running on the remote machine

If you have access to the remote machine (via console, reboot, or another method), verify the SSH daemon is running:

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

If it's not running, start it:

bash
sudo systemctl start ssh
4Check if your IP is blocked by the server

Review the SSH server's access control lists. On the remote machine:

bash
# Check if your IP is in the deny list
sudo grep your_ip /etc/hosts.deny

# Check SSH daemon logs for blocked connections
sudo tail -50 /var/log/auth.log
# or on some systems
sudo tail -50 /var/log/secure

# Check if fail2ban has blocked your IP
sudo fail2ban-client status sshd

If your IP is listed in /etc/hosts.deny, comment it out or remove it. If fail2ban has blocked you, unban your IP with:

bash
sudo fail2ban-client set sshd unbanip your_ip
5Temporarily disable firewall to test (if safe to do so)

If you control the remote machine, temporarily disable the firewall to determine if it's the cause:

bash
# On systems with UFW
sudo ufw disable

# On systems with firewalld
sudo firewall-cmd --state
sudo systemctl stop firewalld

# On systems with iptables
sudo iptables -F

Attempt an SSH connection. If it succeeds with the firewall disabled, reconfigure firewall rules to allow port 22:

bash
# UFW: Allow SSH
sudo ufw allow 22/tcp
sudo ufw enable

# firewalld: Allow SSH
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

# iptables: Accept SSH
sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
6Review SSH daemon configuration for obvious errors

If you have access to the server, check the SSH configuration file for misconfigurations:

bash
sudo sshd -t  # Test configuration syntax

Common issues in /etc/ssh/sshd_config:
- MaxStartups too low (default 10 unauthenticated connections). Increase if needed:

bash
MaxStartups 100:10:300

- ListenAddress bound to localhost only (change to 0.0.0.0 or specific interface)
- Restrictive AllowUsers or DenyUsers directives excluding your user
- Incorrect file permissions (sshd requires specific permissions)

After making changes, restart the service:

bash
sudo systemctl restart ssh
7If connecting through a proxy or bastion host, test via that host

If you're connecting through a jump host or proxy:

bash
ssh -J proxy_user@proxy_host user@target_host

Or use ProxyCommand:

bash
ssh -o ProxyCommand='ssh -W %h:%p proxy_user@proxy_host' user@target_host

Test the connection to the proxy itself first, then through it to the target.

Advanced notes

For AWS/Cloud Instances: Ensure the security group allows inbound TCP traffic on port 22 from your IP. The error 'Connection reset by peer' in AWS typically means the security group rule is not permitting SSH traffic.

MaxStartups Parameter: This setting controls how many unauthenticated connections the SSH daemon will accept before throttling. If you're experiencing intermittent connection resets with multiple concurrent SSH attempts, increase this value in sshd_config. Each connection attempt counts as 'unauthenticated' until credentials are verified.

SSH Key Exchange Algorithms: In rare cases, a mismatch between client and server key exchange algorithms can cause this error. Check available algorithms with ssh -Q kexalgorithms and verify your server supports them. Older servers may need explicit algorithm specification: ssh -o KexAlgorithms=diffie-hellman-group1-sha1 user@host (though this is a security risk with older algorithms).

Client-Side Timeouts: You can increase the client-side timeout if the server is slow to respond:

bash
ssh -o ConnectTimeout=30 -o ServerAliveInterval=60 user@host

Intermittent Issues: If the error is intermittent (sometimes works, sometimes fails), it suggests network instability or the remote SSH service is restarting. Check SSH daemon logs with journalctl -u ssh -n 50 to see when connections are being reset.

Frequently asked questions

What does "ssh_exchange_identification: read: Connection reset by peer" mean?
The error "ssh_exchange_identification: read: Connection reset by peer" occurs when the SSH server abruptly terminates the connection during the identification and key exchange phase of the SSH handshake. The "Connection reset by peer" message means the server unexpectedly closed the TCP connection before completing the SSH protocol handshake. Unlike a "connection timeout" error where the connection simply hangs, this error indicates the server actively rejected or dropped the connection.
How do I fix "ssh_exchange_identification: read: Connection reset by peer"?
The SSH client receives a connection reset error during the key exchange phase when attempting to establish an SSH connection. This typically indicates a network issue, firewall blocking, or SSH server misconfiguration.
What causes "ssh_exchange_identification: read: Connection reset by peer"?
A firewall (local, remote, or intermediate network) is blocking or dropping SSH traffic on port 22 The SSH server is not running or has crashed on the remote machine SSH daemon is configured to reject connections (MaxStartups exceeded, AllowUsers restrictions, etc.)
Is the "ssh_exchange_identification: read: 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