ssh_exchange_identification: read: Connection reset by peer -

This topic describes how to resolve the following issue: The "ssh_exchange_identification: read: Connection reset by peer" error message appears when you connect to a Linux Elastic Computer Service (ECS) instance from an SSH client.

Problem description

When you connect to a Linux instance from an SSH client, the following error message appears even if you use a correct username and password:

ssh_exchange_identification: read: Connection reset by peer.
sshd[11949]: refused connect from 192.168.0.0 (192.168.0.0).

Causes

The issue may occur because of the following reasons:

TCP Wrapper configuration files on the instance contain errors. TCP Wrapper is a tool used in Linux operating systems to control access to network services. In most cases, the tcpd daemon of TCP Wrapper checks the /etc/hosts.allow and /etc/hosts.deny files to determine whether to allow TCP connections from an IP address or a host. If the /etc/hosts.allow or /etc/hosts.deny file contains configuration errors, exceptions occur in SSH connections. To resolve the issue, you can modify the /etc/hosts.allow or /etc/hosts.deny file. For more information, see the Method 1: Modify TCP Wrapper configuration files section of this topic.
The liblz4.so.1 file on the instance is lost. The file is the symbolic link to the liblz4.so.1.7.5 file. If the liblz4.so.1 file is lost, exceptions occur in SSH connections. For more information, see the Method 2: Create the liblz4.so.1 symbolic link section of this topic.
Connection errors occur in the network to which your on-premises device is connected. You must check the network for connection errors. For more information, see the Method 3: Check the network of the on-premises device section of this topic.

Solutions

Method 1: Modify TCP Wrapper configuration files

You can modify the configuration files to dynamically configure the access control policy without the need to restart the instance for the configurations to take effect. This section describes how to modify the /etc/hosts.deny file.

Connect to the ECS instance by using Virtual Network Computing (VNC).
For more information, see Connect to an instance using VNC.
Run the following command to check whether the /etc/hosts.allow or /etc/hosts.deny file contains configurations that deny connections, such as all:all:deny or sshd:<IP address>:deny:
```
cat /etc/hosts.deny
```
- If the files do not contain configurations such as all:all:deny or sshd:<IP address>:deny, the issue is not caused by TCP Wrapper. In this case, use other solutions to troubleshoot the issue.
- If a file contains configurations such as all:all:deny or sshd:<IP address>:deny, proceed to the next step. In this example, the /etc/hosts.deny file contains the configurations.
Modify the /etc/hosts.deny file.
1. Open the /etc/hosts.deny file.
2. Add a number sign (#) before each line that contains all:all:deny or sshd:<IP address>:deny to comment out the lines.
```
# all:all:deny
# sshd:<IP address>: deny 
```
3. Press the Esc key to exit Insert mode.
4. Enter :wq and press the Enter key to save the changes and exit the file.

Method 2: Create the liblz4.so.1 symbolic link

Connect to the ECS instance by using VNC.
For more information, see Connect to an instance using VNC.
Run the following command to query the liblz4.so.1.7.5 file:
```
find / -name "liblz4*"
```
If the liblz4.so.1.7.5 file does not exist, copy the liblz4.so.1.7.5 file from a healthy ECS instance to the /usr/lib64/ directory of the current ECS instance.

Run the following command to create a symbolic link:

ln -s /usr/lib64/liblz4.so.1.7.5 /usr/lib64/liblz4.so.1

Method 3: Check the network of the on-premises device

Connect your on-premises device to another network such as a 4G mobile network, and check whether you can connect to the instance from the on-premises device.

If you can connect to the instance, the original network has connection errors. Troubleshoot the errors.