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.
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.
Run SSH with verbose flags (-v, -vv, or -vvv) to see detailed diagnostic information about where the connection fails:
ssh -vvv user@hostnameThis will show the exact stage where the connection resets (key exchange, negotiation, etc.) which helps identify the cause.
Confirm the remote host is reachable on the network:
ping hostnameAlso test with a port scanner to verify port 22 is accessible:
nc -zv hostname 22
# or
telnet hostname 22If ping works but port 22 is unreachable, the issue is almost certainly a firewall.
If you have access to the remote machine (via console, reboot, or another method), verify the SSH daemon is running:
sudo systemctl status ssh
# or on some systems
sudo service sshd statusIf it's not running, start it:
sudo systemctl start sshReview the SSH server's access control lists. On the remote machine:
# 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 sshdIf your IP is listed in /etc/hosts.deny, comment it out or remove it. If fail2ban has blocked you, unban your IP with:
sudo fail2ban-client set sshd unbanip your_ipIf you control the remote machine, temporarily disable the firewall to determine if it's the cause:
# 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 -FAttempt an SSH connection. If it succeeds with the firewall disabled, reconfigure firewall rules to allow port 22:
# 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 ACCEPTIf you have access to the server, check the SSH configuration file for misconfigurations:
sudo sshd -t # Test configuration syntaxCommon issues in /etc/ssh/sshd_config:
- MaxStartups too low (default 10 unauthenticated connections). Increase if needed:
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:
sudo systemctl restart sshIf you're connecting through a jump host or proxy:
ssh -J proxy_user@proxy_host user@target_hostOr use ProxyCommand:
ssh -o ProxyCommand='ssh -W %h:%p proxy_user@proxy_host' user@target_hostTest the connection to the proxy itself first, then through it to the target.
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:
ssh -o ConnectTimeout=30 -o ServerAliveInterval=60 user@hostIntermittent 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.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH