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

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 662 views

This error occurs when the SSH server abruptly terminates the connection during the key exchange phase, before authentication completes. It's typically caused by firewall blocking, network issues, server misconfiguration, or resource exhaustion.

Quick fix

Fixes Read from remote host hostname: Connection reset by peer

ssh -vvv user@hostname
  1. Enable verbose mode to see where the connection fails
  2. Verify basic network connectivity to the host
  3. Check if port 22 is open and listening on the server
  4. Restart the SSH daemon on the server
ssh — error
ssh -vvv user@hostname
Read from remote host hostname: Connection reset by peer

What this error means

The 'Connection reset by peer' error indicates that the SSH server closed the connection without a graceful handshake. This usually happens during the initial key exchange (KEX) phase, when the client and server are negotiating cryptographic parameters. If the server resets the connection at this early stage, it prevents SSH from even reaching the authentication step. Common culprits include firewall rules blocking port 22, SSH daemon misconfiguration, server overload, or TCP wrappers (access control lists) rejecting the connection.

Typical symptoms

  • SSH connection attempt immediately fails with 'Connection reset by peer'
  • Connection succeeds from some networks but fails from others
  • Error appears consistently when connecting to a specific host
  • SSH works briefly then disconnects after a few seconds
  • Verbose mode (-v flag) shows connection reset during key exchange
  • Other services can reach the host but SSH cannot

Common causes

  1. Firewall or security group rules blocking SSH traffic on port 22
  2. TCP wrappers (/etc/hosts.deny or /etc/hosts.allow) rejecting the client IP
  3. SSH daemon (sshd) not running or recently crashed on the server
  4. SSH configuration file (sshd_config) has invalid syntax or restrictive settings
  5. Server resource exhaustion (memory, CPU, or connection limits reached)
  6. Intrusion prevention software or fail2ban blocking repeated connection attempts
  7. Network routing issues or high packet loss causing premature disconnection
  8. Encryption algorithm mismatch between client and server
  9. MTU (Maximum Transmission Unit) mismatch causing IP fragmentation issues

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

1Enable verbose mode to see where the connection fails

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

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

2Verify basic network connectivity to the host

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

bash
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.

3Check if port 22 is open and listening on the server

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

bash
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.

4Restart the SSH daemon on the server

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

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

5Check firewall rules blocking port 22

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

UFW (Ubuntu/Debian):

bash
sudo ufw status
sudo ufw allow 22/tcp

firewalld (RHEL/CentOS):

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

iptables (manual):

bash
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.

6Check TCP wrappers access control lists

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

bash
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:

bash
sudo systemctl restart ssh

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

bash
sshd: 192.168.1.100  # Allow specific IP
sshd: 192.168.1.0/24 # Allow subnet
7Verify SSH daemon configuration for errors

Check if sshd_config has invalid syntax or overly restrictive settings:

bash
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:

bash
sudo systemctl restart ssh
8Try connecting from a different IP or network

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

bash
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:

bash
sudo fail2ban-client set sshd unbanip YOUR_IP
9Check server logs for connection rejection reasons

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

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

10Check server resources and connection limits

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

bash
# 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:

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

Then restart:

bash
sudo systemctl restart ssh
11Try different SSH key algorithms or ciphers (advanced)

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

bash
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)

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

Then restart and test.

Advanced notes

MTU and fragmentation issues: In some network environments, packet fragmentation during the SSH handshake can cause connection resets. If you suspect this, try reducing the MTU on your client machine: sudo ip link set dev eth0 mtu 1400 (adjust eth0 to your interface). Then test SSH again.

SELinux interference: On systems with SELinux enabled, a misconfigured policy might block SSH connections. Check: getenforce and sudo ausearch -m AVC -ts recent | grep sshd. If you see denials, either adjust the policy or temporarily disable SELinux for testing: sudo setenforce 0 (temporary, requires root).

SSH timeouts and keep-alive: To prevent future connection resets during idle periods, configure keep-alive on the client side. Add to your ~/.ssh/config:

bash
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

This sends a keep-alive packet every 60 seconds and allows up to 3 missed packets before disconnecting.

Rate limiting and intrusion detection: Services like fail2ban or DenyHosts protect against brute-force attacks by blocking IPs after multiple failures. If locked out, wait for the ban window to expire (typically 10-24 hours) or ask your server admin to manually unban. Avoid repeatedly retrying immediately, as it resets the timer.

Frequently asked questions

What does "Read from remote host hostname: Connection reset by peer" mean?
The 'Connection reset by peer' error indicates that the SSH server closed the connection without a graceful handshake. This usually happens during the initial key exchange (KEX) phase, when the client and server are negotiating cryptographic parameters. If the server resets the connection at this early stage, it prevents SSH from even reaching the authentication step.
How do I fix "Read from remote host hostname: Connection reset by peer"?
This error occurs when the SSH server abruptly terminates the connection during the key exchange phase, before authentication completes. It's typically caused by firewall blocking, network issues, server misconfiguration, or resource exhaustion.
What causes "Read from remote host hostname: Connection reset by peer"?
Firewall or security group rules blocking SSH traffic on port 22 TCP wrappers (/etc/hosts.deny or /etc/hosts.allow) rejecting the client IP SSH daemon (sshd) not running or recently crashed on the server
Is the "Read from remote host hostname: 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