kex_exchange_identification read connection reset by peer Causes & Solution

Secure Shell (SSH) connection is used to communicate between two machines, even when both machines do not run the same operating system.

It is one of the oldest secure remote control protocols, designed for Unix-based operating systems to replace the aging and insecure Telnet or Berkeley Remote Shell protocol.

Nowadays, the use of SSH has expanded beyond simple workstation sharing or remote access. Various other applications have now developed on the backbone of SSH, such as secure file sharing using SFTP (FTP over SSH) and Git/SVN version control system for developers.

By default, SSH takes security very seriously. Only connections from specific IP addresses using specific authentication methods are allowed by the SSH daemon.

So, what happens if you try to authenticate using an unsupported client, IP address, or authentication method? Your connection will be rejected in the name of security.

This might prove to be frustrating for beginner or intermediate users, especially if they only use SSH for Git purposes.

What Caused the Issue?

Getting the error message “kex_exchange_identification read connection reset by peer” might prove frustrating for almost everyone, but in this article, we will delve down into the reasons why this error occurs, and how to solve this.

The first thing to consider is the way the SSH server and client communicate. When you connect your SSH client to a server, the server will begin the connection by sending a version string to your client.

However, this error occurs when the client was waiting for the server to send the data. After the TCP link is dropped, you will see the error message.

It can mean that the server is crashing/malfunctioning after receiving your connection request, or there is something else preventing the connection.

How to Fix it?

First of all, try connecting to the server with another machine or IP address as the security setting of your server might be rejecting the connection request.

If you are not using a VPN, try connecting through a VPN, and vice versa – if you usually connect with VPN, try connecting to your server using your original IP address.

You can also check your routing table to the server to see whether there is a route drop in your connection. As its name implies, routing tables are used to route packets from your computer to another computer.

In Linux, you can check the routing table using the command:

route -n

If you see an anomaly, such as an incomplete link, you can reboot your router or your computer. Or, if you think one of the routes is the culprit, you can exclude that route entirely using the following command:

route del xxx.xxx.xxx.xxx/xx via xxx.xxx.xxx.xxx

After excluding routes, rebooting your computer, or rebooting your router, try to connect to the server again.

If all else fails, you will need to contact the technical support of your server company to see if they can fix your appliance for you. As a pointer, tell the tech support to check these files:

/etc/hosts.deny

AND

/etc/hosts.allow

Both files operated as the “blacklist” or “whitelist”, containing the IP address and hostnames that are allowed or denied access to the remote system.

See if your IP or hostname is on either list – if not, please ask the tech support to add your IP to the hosts.allow. Sometimes, after specifying your IP address in the whitelist, you need to restart the SSH daemon or the entire server. Be patient and try reconnecting later on.

Another factor to consider is that the server might be secured by another security solution such as fail2ban.

Fail2ban is a software that monitors malicious user intents and automatically bans certain IP addresses from ever connecting to the server again. Some of the malicious signs include too many password failures, connecting to find exploits, etc.

If it is the case, you need to clean up your computer first from viruses, malware, and other security problems before trying to connect to the server.

Or, if you are certain that your computer does not contain any malware, you can ask the technical support to uncomment the line

ignoreip = 127.0.0.1/8 ::1

In the file:

/etc/fail2ban/jail.conf

Afterward, ask the technical support guy to insert your IP address to the ignoreip line, and try reconnecting. Now, you should be connected properly to your server, ready to do any actions.

Node35 Editorial Team

We are a bunch of people who are still continue to learn Linux servers. Only high passion keeps pushing us to learn everything.