Fix kex_exchange_identification connection reset by peer SSH Error

Encountering errors while managing your servers can be frustrating. One common issue that sysadmins and developers face is the dreaded "kex_exchange_identification connection reset by peer" error when attempting to SSH into a server or check its status. But don’t panic! This seemingly cryptic message isn’t necessarily indicative of a major network meltdown. More often than not, it’s a solvable configuration or security hiccup.

This article will delve into the meaning behind the "kex_exchange_identification connection reset by peer" error, explore its common causes, and provide step-by-step solutions to get you back up and running.

What Does “kex_exchange_identification connection reset by peer” Even Mean?

When you initiate an SSH connection, your computer and the server engage in a cryptographic handshake. This process, known as key exchange (KEX), establishes a secure, encrypted tunnel for communication. The "kex_exchange_identification connection reset by peer" error signifies that this initial handshake failed. Specifically, the server terminated the connection prematurely, sending a "reset" signal before the key exchange could complete. This premature termination often stems from a security rule, configuration problem, or a mismatch in expectations between the client and server.

What Causes the kex_exchange_identification read Error?

Several factors can trigger this error:

• Firewall settings: A restrictive firewall on the server might be blocking SSH connections.
• SSH server not running correctly: The SSH daemon (sshd) might be stopped, misconfigured, or experiencing issues.
• IP bans: Security tools like Fail2ban could be blocking your IP address due to repeated failed login attempts.
• Too many open SSH connections: The server might be configured to limit the number of concurrent SSH connections.
• Incorrect SSH configs: Errors or inconsistencies in the SSH server configuration file (sshd_config) can disrupt the connection process.
• Network Issues: Although the opening paragraph states that the error is not a network problem, sometimes there are underlying network issues that cause the SSH handshake to fail.

Resolve connection reset by peer SSH Error

Let’s walk through the steps to troubleshoot and resolve the "kex_exchange_identification connection reset by peer" error:

1. Verify SSH Server is Running Correctly

The first and most basic step is to ensure that the SSH server is actively running on the target machine. Use the following command to check its status:

sudo systemctl status sshd

The output should indicate that the service is "active (running)".

If SSH is not running, enable and start it using these commands:

# sudo systemctl enable sshd
# sudo systemctl start sshd

2. Check Firewall Settings for SSH Server

Firewalls are crucial for security, but they can inadvertently block legitimate SSH traffic. If you’re using UFW (Uncomplicated Firewall), ensure that it’s enabled and configured to allow SSH connections.

Install and enable UFW:

# sudo apt install ufw -y
# sudo ufw enable

Allow traffic on the default SSH port (22):

sudo ufw allow 22/tcp

If you’ve changed the default SSH port, allow traffic on your custom port (e.g., 2222):

sudo ufw allow 2222/tcp

Finally, reload the firewall to apply the changes:

sudo ufw reload

3. Check If You are Banned by Server

Fail2ban and similar tools automatically block IP addresses after a certain number of failed login attempts, a measure to prevent brute-force attacks. To check if your IP has been blacklisted by Fail2ban, use this command:

sudo fail2ban-client status

Examine the output to see if your IP address is listed as banned. If it is, you can unban it with the following command, replacing <mark>YOUR-IP-ADDRESS</mark> with your actual IP:

sudo fail2ban-client set sshd unbanip <mark>YOUR-IP-ADDRESS</mark>

4. Secure SSH Server Config

Enhance your SSH server’s security by disabling root logins, using SSH key authentication, and changing the default SSH port.

Open the SSH configuration file:

sudo vi /etc/ssh/sshd_config

Modify the following lines to change the port and disable root logins:

Port <mark>2222</mark>
PermitRootLogin <mark>no</mark>

Save the changes and restart the SSH service:

sudo systemctl restart sshd

Remember to update your firewall rules to reflect the new SSH port.

The "kex_exchange_identification connection reset by peer" error can often be fixed by following these steps.

Alternative Solutions

While the above methods cover the most common causes and solutions, here are two alternative approaches to tackle the "kex_exchange_identification connection reset by peer" error:

1. Address MTU (Maximum Transmission Unit) Issues

Sometimes, the "kex_exchange_identification connection reset by peer" error arises due to MTU (Maximum Transmission Unit) mismatch between the client and the server. MTU refers to the largest packet size that can be transmitted over a network connection. If the client’s MTU setting is larger than what the server or any intermediate network device supports, packets can be fragmented, leading to connection issues, including the SSH error in question.

Explanation: Packet fragmentation increases the likelihood of packet loss. During the initial KEX phase of the SSH handshake, reliable packet delivery is crucial. If fragmented packets are lost, the handshake fails, resulting in the "connection reset by peer" error.

Solution:

• Ping with "Don’t Fragment" Flag: Determine the optimal MTU size by pinging the server with the "don’t fragment" (-M do) flag and gradually reducing the packet size until you get a successful ping. For example:

  ping -c 3 -M do -s 1472 <server_ip_address>

  If the ping is successful, try increasing the size. If it fails ("Packet too big"), decrease the size. 1472 + 28 bytes of IP and ICMP headers = 1500, a common MTU value.

• Adjust Client-Side MTU: Once you’ve determined a suitable MTU size, adjust your client’s network interface MTU accordingly. The specific command depends on your operating system and network configuration. For example, on Linux:

  sudo ip link set mtu 1472 dev <network_interface>

  Replace <network_interface> with the name of your network interface (e.g., eth0, wlan0).

• Consider Path MTU Discovery (PMTUD): Ensure that PMTUD is enabled on both the client and server. PMTUD allows devices to dynamically discover the smallest MTU along the network path. This is often enabled by default but can be disabled by firewalls or network configurations.

2. Investigate Client-Side SSH Configuration

The issue might not always reside on the server. Client-side SSH configurations can also contribute to the "kex_exchange_identification connection reset by peer" error.

Explanation: Incompatible cipher suites, key exchange algorithms, or other configuration parameters on the client side can prevent a successful SSH handshake with the server.

Solution:

• Verbose SSH Connection Attempt: Use the -v (verbose) or -vvv (very verbose) flag when connecting via SSH to get detailed information about the connection process. This can help pinpoint the exact stage where the failure occurs.

  ssh -vvv <user>@<server_ip_address>

  Examine the output for any errors or warnings related to key exchange, cipher negotiation, or other configuration issues.

• Specify Key Exchange Algorithms: Explicitly specify the key exchange algorithms to use in your SSH command. This can help if the client and server are failing to negotiate a mutually supported algorithm.

  ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 <user>@<server_ip_address>

  Try different key exchange algorithms to see if one works. You can get a list of supported algorithms by running ssh -Q kex. Note: Using older algorithms like diffie-hellman-group14-sha1 might be less secure; prioritize stronger algorithms if possible. Only use weaker algorithms if you’re troubleshooting compatibility issues with legacy systems.

• Check SSH Client Configuration File: Examine your SSH client configuration file (~/.ssh/config or /etc/ssh/ssh_config) for any potentially conflicting or incorrect settings. Pay attention to settings like KexAlgorithms, Ciphers, HostKeyAlgorithms, and StrictHostKeyChecking.

Conclusion

The "kex_exchange_identification connection reset by peer" error is a common SSH issue that, fortunately, is usually resolvable. By systematically checking the SSH server status, firewall settings, potential IP bans, and SSH configurations (both server and client side), you can effectively diagnose and fix the problem. Remember to consider MTU issues and explore verbose SSH output for deeper insights. With a bit of troubleshooting, you can restore your SSH connectivity and get back to managing your servers with ease.