How to fix Read from remote host hostname: Connection reset by peer in SSH

Run your SSH command with the -vvv flag to get detailed debugging output:

ssh -vvv user@hostname

This shows exactly which phase (key exchange, authentication, etc.) the connection is reset. Look for lines mentioning 'kex_exchange_identification' or 'read protocol version'.

Take note of the verbose output—it often reveals the exact problem (e.g., 'Received disconnect message' with a reason code).

First, confirm the host is reachable at the network level:

ping -c 4 hostname
traceroute hostname

If ping succeeds but SSH fails, the host is online but specifically rejecting SSH. If ping fails, the host is unreachable—contact your network admin or check if the host is down.

From the server itself (if you have direct access), verify SSH is listening:

sudo netstat -tuln | grep :22
# or
sudo ss -tuln | grep :22

Look for a line like tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN. If nothing appears, the SSH daemon is not running.

If you have direct access to the server (console, or working SSH session from another machine):

# On systemd systems
sudo systemctl restart ssh
# or
sudo systemctl restart sshd

# On older systems
sudo service ssh restart
sudo /etc/init.d/ssh restart

Wait 5-10 seconds, then try connecting again from your client.

If you manage the server's firewall, verify SSH traffic is allowed:

UFW (Ubuntu/Debian):

sudo ufw status
sudo ufw allow 22/tcp

firewalld (RHEL/CentOS):

sudo firewall-cmd --list-ports
sudo firewall-cmd --add-port=22/tcp --permanent
sudo firewall-cmd --reload

iptables (manual):

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

If using a cloud provider (AWS, Azure, GCP), also check your security group or network security group rules allow inbound SSH.

Examine if your IP is blocked in /etc/hosts.deny or restricted by /etc/hosts.allow:

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

If you see entries like sshd: ALL in hosts.deny, or your IP is missing from hosts.allow, that's the problem.

To allow all SSH connections:
Comment out or remove blocking lines, then restart SSH:

sudo systemctl restart ssh

To allow only specific IPs:
Add to /etc/hosts.allow:

sshd: 192.168.1.100  # Allow specific IP
sshd: 192.168.1.0/24 # Allow subnet

Check if sshd_config has invalid syntax or overly restrictive settings:

sudo sshd -t  # Test SSH config syntax

If there's an error, it will show the line number. Common problematic settings:

- AllowUsers or DenyUsers excluding your username
- Match blocks with incorrect conditions
- MaxStartups set too low (default 10:30:60)
- Port changed from default 22

Edit /etc/ssh/sshd_config to fix, then:

sudo systemctl restart ssh

If possible, attempt SSH from a different client machine or network (e.g., mobile hotspot, different office, VPN):

ssh user@hostname

If this succeeds, your original IP may be blacklisted. Check:
- fail2ban on the server: sudo fail2ban-client status sshd
- DenyHosts if installed
- Cloud provider IP reputation filters

To unban yourself from fail2ban:

sudo fail2ban-client set sshd unbanip YOUR_IP

The server logs often reveal exactly why it reset the connection:

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

# RHEL/CentOS
sudo tail -f /var/log/secure

# BSD/macOS
sudo log stream --level debug --predicate 'process == "sshd"'

Look for entries with your IP address. Messages like 'Invalid user', 'Connection reset by peer', or 'Received disconnect' will indicate the cause. Use this info to adjust sshd configuration or firewall rules.

If the server is overloaded, it may drop new connections:

# Check CPU and memory usage
top
# or
htop

# Check current SSH connections
ss -tn | grep :22 | wc -l

# Check MaxStartups setting
sudo grep MaxStartups /etc/ssh/sshd_config

If approaching the limit, increase in sshd_config:

MaxStartups 100:30:200  # Allow more concurrent unauthenticated connections
MaxSessions 50          # Allow more total sessions per connection

Then restart:

sudo systemctl restart ssh

If client and server have no compatible encryption algorithms, connection fails early. Test with legacy algorithms:

ssh -oKexAlgorithms=diffie-hellman-group1-sha1 user@hostname
ssh -oCiphers=aes128-cbc user@hostname

If one of these works, your default algorithms are incompatible. Consider:
- Upgrading SSH server software
- Temporarily enabling legacy algorithms in sshd_config (not recommended long-term)

KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc

Then restart and test.