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

SSHINTERMEDIATEHIGHUpdated May 28, 2026· 3,587 views

The SSH server reset the connection during key exchange. Fix by checking firewall/fail2ban, MaxStartups, or port 443 SSH.

Quick fix

Fixes kex_exchange_identification: read: Connection reset by peer

ping <server-ip>
traceroute <server-ip>
telnet <server-ip> 22
  1. Check network connectivity to the SSH server
  2. Check if your IP is blocked by fail2ban
  3. Verify SSH daemon is running on the remote server
  4. Check firewall rules on both client and server
ssh — error
ping <server-ip>
traceroute <server-ip>
telnet <server-ip> 22
kex_exchange_identification: read: Connection reset by peer

What this error means

This error occurs during the SSH key exchange (KEX) phase, which is the first critical step of establishing a secure connection. The 'read: Connection reset by peer' message means the remote SSH server intentionally closed the TCP connection before the client could finish the key exchange handshake. This can happen for several reasons: the server may be rejecting your IP address, under heavy load, misconfigured, or your network may have a firewall blocking the connection.

Typical symptoms

  • SSH connections immediately fail with no authentication prompt
  • Connection appears to start (TCP handshake succeeds) then abruptly closes
  • Error occurs before you see any password or key prompts
  • Works from some networks but not others
  • Works from different client machines to the same server
  • Intermittent failures that may resolve after waiting

Common causes

  1. Firewall or network security device blocking port 22 or resetting connections mid-handshake
  2. Your IP address blocked by fail2ban, DenyHosts, or similar security tools after previous failed attempts
  3. SSH server overloaded or at MaxStartups connection limit, refusing new unauthenticated connections
  4. SSH daemon not fully running or recently restarted on the remote server
  5. Key exchange algorithm mismatch between old client and new server (or vice versa)
  6. Missing or corrupted SSH host keys on the remote server
  7. TCP Wrappers or /etc/hosts.allow/hosts.deny restrictions blocking your IP
  8. Network instability, high latency, or ISP interference during initial handshake

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

1Check network connectivity to the SSH server

First verify that the remote server is reachable:

bash
ping <server-ip>
traceroute <server-ip>
telnet <server-ip> 22

If ping fails or traceroute hangs, you have a network connectivity issue. If telnet connects and immediately disconnects, the SSH server is running but rejecting your connection.

2Check if your IP is blocked by fail2ban

From the server (if you have local access or another login method), check fail2ban status:

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

If your IP appears in the 'Banned IP list', unban it using the second command. This is the most common cause of this error.

3Verify SSH daemon is running on the remote server

If you have local server access or another login method:

bash
sudo systemctl status ssh
sudo systemctl status sshd

If the service is inactive:

bash
sudo systemctl start ssh

Or if using older init systems:

bash
sudo service ssh start
4Check firewall rules on both client and server

On the server, verify port 22 is open:

bash
sudo iptables -L -n | grep 22
sudo ufw status

On the client, check if your firewall or ISP is blocking outbound SSH:

bash
telnet <server-ip> 22

If using a cloud provider (AWS, Azure, GCP), check the security group or firewall rules to ensure inbound TCP 22 is allowed from your IP.

5Verify SSH host keys exist and are not corrupted

From the server:

bash
ls -la /etc/ssh/ssh_host_*

You should see files like ssh_host_rsa_key, ssh_host_ed25519_key, etc. If they are missing or the directory is empty, regenerate them:

bash
sudo ssh-keygen -A
sudo systemctl restart ssh
6Enable verbose SSH mode for detailed debugging

Run your SSH command with increased verbosity:

bash
ssh -vvv user@hostname

The output will show exactly where the connection fails. Look for lines like:
- 'SSH2_MSG_KEXINIT sent' - if you see this and then 'Connection reset', the server is dropping you during KEX
- 'Authentications that can continue' - you got past KEX, so the issue is authentication

7Check MaxStartups and SSH configuration limits

If the server is under heavy load:

bash
sudo grep MaxStartups /etc/ssh/sshd_config

Default is 10:30:60 (max 10 concurrent unauthenticated connections). If your server has high traffic:

bash
# In /etc/ssh/sshd_config:
MaxStartups 30:60:120

# Then restart:
sudo systemctl restart ssh
8Try from a different network or use a VPN

Attempt the connection:
- From a different ISP or network
- Through a VPN
- Via a bastion/jump host (if available)

If it works through a VPN but not your normal connection, your ISP may be interfering with SSH traffic. Try connecting to a non-standard SSH port (if your server supports it):

bash
ssh -p 2222 user@hostname
9Update SSH client and server to latest versions

Ensure compatibility by running the latest SSH implementations:

bash
# On client (macOS/Linux):
ssh -V

# On server, update OpenSSH:
sudo apt update && sudo apt install openssh-server openssh-client
# or
sudo yum update openssh-clients openssh-server

After updating the server, restart SSH:

bash
sudo systemctl restart ssh
10Clear SSH known_hosts if needed

If the server's host key has changed or you're getting conflicting entries:

bash
ssh-keygen -R <server-ip>
ssh-keygen -R <hostname>

Then try connecting again. You will get a prompt to accept the new host key.

Advanced notes

Key Exchange Algorithm Mismatches: If the client and server support different key exchange algorithms, KEX will fail. Check sshd_config for 'KexAlgorithms' and ensure your client supports at least one. Use ssh -Q kex to see your client's supported algorithms.

Rootless SSH Servers: Some sandboxed or containerized SSH setups may have restrictions. Verify the SSH process has appropriate network capabilities.

TCP Wrappers: Even if iptables allows SSH, /etc/hosts.allow and /etc/hosts.deny can block connections:

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

If your IP is in 'deny', add it to 'allow':

bash
# /etc/hosts.allow
sshd: <your-ip>

Intermittent Failures: If this only happens occasionally, check system logs during failure:

bash
sudo tail -f /var/log/auth.log      # Debian/Ubuntu
sudo tail -f /var/log/secure        # RHEL/CentOS
sudo log stream --predicate 'eventMessage contains[cd] sshd' --info  # macOS

Frequently asked questions

What does "kex_exchange_identification: read: Connection reset by peer" mean?
This error occurs during the SSH key exchange (KEX) phase, which is the first critical step of establishing a secure connection. The 'read: Connection reset by peer' message means the remote SSH server intentionally closed the TCP connection before the client could finish the key exchange handshake. This can happen for several reasons: the server may be rejecting your IP address, under heavy load, misconfigured, or your network may have a firewall blocking the connection.
How do I fix "kex_exchange_identification: read: Connection reset by peer"?
The SSH server reset the connection during key exchange. Fix by checking firewall/fail2ban, MaxStartups, or port 443 SSH.
What causes "kex_exchange_identification: read: Connection reset by peer"?
Firewall or network security device blocking port 22 or resetting connections mid-handshake Your IP address blocked by fail2ban, DenyHosts, or similar security tools after previous failed attempts SSH server overloaded or at MaxStartups connection limit, refusing new unauthenticated connections
Is the "kex_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