How to Fix "ssh_exchange_identification: read: Connection reset by peer" Error

Introduction

The “ssh_exchange_identification: read: Connection reset by peer” message occurs when a remote machine prevents an SSH connection. The error is not specific enough to immediately explain what triggered it. To be able to resolve the issue successfully, you must identify its cause.

This tutorial will show how to fix the “ssh_exchange_identification: read: Connection reset by peer” error, with an in-depth analysis of the likely causes and the most effective solutions.

Prerequisites

• Necessary permissions to access a remote server.
• A user account with root privileges.

Meaning of "ssh_exchange_identification: read: Connection reset by peer" Error

The "ssh_exchange_identification: read: Connection reset by peer" error occurs due to a sudden termination of the connection by the server during the identification phase. In that context, the "Connection reset by peer" segment means that the server halted the connection without providing any essential identification details.

The error usually happens when initiating an SSH connection to a remote server. The term "ssh_exchange_identification" denotes the crucial step in the connection setup process where both the client and server exchange identification information. This exchange is fundamental for establishing a secure connection.

The error often indicates a disruption in the handshake between the client and the server, which requires a thorough investigation of potential causes. Common factors contributing to this issue include network instability, misconfigurations in SSH settings, or even security mechanisms on the server side.

The sections below explore the possible causes and fixes for the error.

What Causes the "ssh_exchange_identification: read: Connection reset by peer" Error?

The "ssh_exchange_identification: read: Connection reset by peer" error can be triggered by various factors, with the most common being:

• Network Issues. Unstable or high-latency network connections can result in the abrupt termination of the SSH connection.
• Firewall Restrictions. Firewalls, either on the client or server side, might block the required communication for proper SSH identification.
• SSH Misconfiguration. Incorrect SSH settings, authentication issues, or incompatible key exchange algorithms can lead to the connection reset error.

In most instances, configuring how SSH works or rebooting the remote server solves a temporary outage or connectivity issue. Learning to troubleshoot the issue and determining the underlying cause helps you prevent the issue in the future.

Troubleshooting the "ssh_exchange_identification: read: Connection reset by peer" Error

When the "ssh_exchange_identification: read: Connection reset by peer" error occurs, effective troubleshooting is crucial for identifying and resolving the underlying issues. In the following sections, we will explore various methods to diagnose and address the causes of this error.

Restart sshd Daemon on Server

The sshd daemon is a background process that runs on a server and manages incoming SSH connections. It is a crucial component of the SSH protocol, providing encrypted communication over a network.

A possible solution for the "ssh_exchange_identification: read: Connection reset by peer" error is to restart the sshd daemon on the server. If you are using Linux, run the command below to restart the service:

sudo systemctl restart sshd

The command restarts the service, and you can retry to connect to see if the error is gone.

Check SSH Server Status

Checking the SSH server status is an essential step in troubleshooting SSH-related issues. To check the sshd service status, run the following command:

sudo systemctl status ssh

If the SSH service is not running or if there are issues, restart it using one of the commands below:

For systems using systemd:

sudo systemctl restart ssh

For systems using init.d:

sudo service ssh restart

After restarting the service, check the status again to ensure it is running without errors.

In case the service is missing, install it and start the openssh-server on Ubuntu by running the commands below:

sudo apt install openssh-server

sudo systemctl start ssh

Ping the Server

Since a weak or failed connection can cause the "ssh_exchange_identification: read: Connection reset by peer" error, it is important to check network connectivity by pinging the server. The connection is stable if the packets are delivered successfully without any packet loss.

Follow our tutorial for using the ping command in Linux and ensure your connectivity is not causing the issue.

Attempt Login With a Different Host

Attempting to log in from a different host helps determine whether the issue is specific to the client or the server. If you encounter the "ssh_exchange_identification: read: Connection reset by peer" error from one client but can successfully connect from another, the problem might be related to the client-side configuration or network.

Connect to the server from a different client machine, such as another computer or a virtual machine. If the connection is successful from a different client, it indicates that the issue is likely on the original client machine.

Check SSH Log File

Checking the SSH log files on the server can help diagnose and resolve the "ssh_exchange_identification: read: Connection reset by peer" error. The log files contain information about the SSH connection attempts, errors, and other relevant details.

The location of the log files varies depending on the operating system. Common locations in different Linux distributions are:

• /var/log/auth.log
• /var/log/secure
• /var/log/auth.log

Open the log file using a text editor and search for entries related to the failed SSH connection attempt. Look for any error messages that might indicate the cause of the connection reset.

Check for any messages indicating issues such as failed authentication, permission problems, or problems with the SSH server configuration, which can help you pinpoint the problem.

Check MaxAuthTries

Having multiple SSH keys on your machine could exceed the value of MaxAuthTries on the server. The setting depicts the maximum number of authentication attempts allowed, and the default value is 6.

To address this issue, increase the value of MaxAuthTries in the sshd configuration file and restart the sshd daemon.

Open the configuration file using a text editor such as nano:

sudo nano /etc/ssh/sshd_config

Find the MaxAuthTries line, uncomment it (remove the # sign), and increase the value or add the line if it doesn't exist in the file.

Check Inactivity Settings

Inactivity settings in the SSH configuration file determine how often the server checks for client activity and the number of times it tolerates no response before disconnecting. If the values are too low, the server may disconnect idle connections too quickly and cause the "ssh_exchange_identification: read: Connection reset by peer" error.

The configuration file is usually located at /etc/ssh/sshd_config and can be edited using a text editor.

Find the following lines and ensure that the values are appropriate:

ClientAliveInterval 300

This parameter defines the interval (in seconds) at which the server sends a keep-alive message to the client to check if the client is still active. A common value is between 300 and 900 seconds (5 to 15 minutes).

ClientAliveCountMax 3

This parameter sets the number of unresponsive keep-alive messages that the server tolerates before disconnecting the client. A common value is between 2 and 5.

After making changes to the config file, restart the SSH service:

sudo service ssh restart

Check hosts.deny File

The hosts.deny and hosts.allow files are TCP wrappers. As a security feature, these files limit which IP address or hostname can establish a connection to the remote machine.

Access your remote server and open the hosts.deny file using a text editor. If you are using nano on a Debian-based system, run the following command:

sudo nano /etc/hosts.deny

Check if you can locate your local IP or hostname in the file. If it is present, remove or comment it out since it will prevent you from establishing a remote connection.

After making the necessary changes, save the file and exit. Attempt to reconnect via SSH.

Check hosts.allow File

As an additional precaution, check the hosts.allow file. Access rules within the hosts.allow are applied first. They take precedence over the rules specified in hosts.deny file.

Run the following command to edit the hosts.allow file:

sudo nano /etc/hosts.allow

Adding hostnames and IPs to the file defines exceptions to the settings in the hosts.deny file.

For example, a strict security policy within the etc/hosts.deny file, would deny access to all hosts:

sshd : ALL
ALL : ALL

Subsequently, you can add a single IP address, an IP range, or a hostname to the etc/hosts.allow file. By adding the following line, only the following IP would be allowed to establish an SSH connection with your remote server:

sshd : 10.10.0.5, LOCAL

Keep in mind that such a limiting security setting can affect administering capabilities on your remote servers.

Check MaxStartups & MaxSessions Settings

The MaxStartups and MaxSessions settings in the SSH server configuration file can help troubleshoot SSH-related issues. The settings control the maximum number of concurrent connections that the SSH server can handle, and adjusting them might be necessary based on the server's capacity and your specific requirements.

MaxStartups determines the maximum number of concurrent unauthenticated connections the SSH server accepts. Additional incoming connection attempts are delayed or refused if this limit is reached.

For example, the following setting allows up to 10 unauthenticated connections immediately, up to 30 connections after 30 seconds, and up to 60 connections after 60 seconds:

MaxStartups 10:30:60

MaxSessions controls the maximum number of open sessions per network connection. It limits the number of simultaneous interactive sessions a single connection can have.

For example, the following setting limits a single network connection to a maximum of 10 simultaneous sessions:

MaxSessions 10

If necessary, adjust the settings to correlate with your server's capacity and needs and see if it resolves the error.

Check Firewall Settings

Firewalls can block incoming or outgoing SSH traffic, preventing successful connections and causing the "ssh_exchange_identification: read: Connection reset by peer" error. Confirm the SSH server is listening on the expected port. The default port for SSH is 22.

You can use the netstat command to check for the SSH server process (sshd) and the port it is listening on:

sudo netstat -tulpn | grep ssh

In the example above, the output shows that the SSH server is listening on all available IPv4 and IPv6 interfaces on port 22.

Examine the firewall rules to verify that they allow incoming SSH traffic. The specific commands vary depending on the firewall software in use:

For systems using ufw:

sudo ufw status

For systems using iptables:

sudo iptables -L

For systems using firewalld:

sudo firewall-cmd --list-all

Look for rules allowing traffic to the SSH port (default is 22). If no rule allows SSH traffic, you may need to add one. Check the specific guides for each firewall type and add the rule.

Check Intrusion Prevention Software

If you tried to connect multiple times, your IP might be blocked by intrusion prevention software. Fail2ban is a service designed to protect you from brute force attacks, and it can misinterpret your authentication attempts as an attack.

Fail2ban monitors and dynamically alters firewall rules to ban IP addresses that exhibit suspicious behavior. It monitors logs like the hosts.deny and hosts.allow files we edited previously.

In our example, we used the following command to check if iptables is rejecting your attempted connections:

sudo iptables -L --line-number

The output lists all authentication attempts. If a firewall is preventing your SSH connection, you can whitelist your IP with fail2ban. Otherwise, the service will block all future attempts continuously.

To access the fail2ban configuration file, run the following command:

sudo nano /etc/fail2ban/jail.conf

Edit the file by uncommenting the line ignoreip = and add the IP or IP range you want to whitelist.

Fail2ban will now make an exception and not report suspicious behavior for the IP in question.

Check Compatibility of SSH Encryption Modes

Check if the software on your machine is compatible with the SSH encryption modes the server supports. Not all software types are compatible with all encryption algorithms, which can be the reason behind the connection error.

If you are unsure, try using a different SSH client or check if your current client is updated to the latest available version. After that, retry to connect to see if the error goes away.

Enable Verbose Mode on SSH Client

Running the SSH client in verbose mode provides detailed information about the connection process, authentication, and any errors. This additional information can help you identify the specific point of failure and understand the nature of the problem.

Use the -v option when running the SSH client to enable verbose mode. For example:

ssh -v user@hostname

This command runs the SSH client in verbose mode for a specific connection, displaying detailed information about the connection process. You can use additional -v flags to increase the verbosity level, for example, -vv or -vvv.

The output shows details about:

• The connection process.
• The authentication methods attempted and the server's response.
• Every cryptographic algorithm negotiated between the client and server.
• Error messages on the connection failure.

If you encounter issues and need further assistance, share the verbose output with an administrator, who can help you resolve the issue.

Server Reboot

If none of the troubleshooting steps above help you resolve the error, the last resort is to reboot the server. Sometimes, the "ssh_exchange_identification: read: Connection reset by peer" error can be caused by exhausted memory on the server, and a reboot is a quick fix.

Make sure there is no critical data in use or running processes, as they will be interrupted, and data could be lost if in use during reboot.

If you are using Linux, run the command below to reboot the server:

sudo reboot

After the reboot, check if the error is gone when reconnecting.

Conclusion

You have thoroughly checked the most common reasons behind the "ssh_exchange_identification: read: Connection reset by peer" error. By looking at each possibility, you have successfully solved the issue and now know how to deal with similar problems going forward.

Next, learn to fix the SSH "Connection refused" error or learn the difference between SSH and SFTP.