What do I do if the "ssh_exchange_identification: read: Connection reset by peer" error message appears when I connect to a Linux instance from an SSH client? - Elastic Compute Service

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 standard security framework that controls access to applications in Linux operating systems. In most cases, the tcpd daemon of TCP Wrapper reads configurations from the /etc/hosts.allow and /etc/hosts.deny files to determine whether to allow TCP connections. 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.
The public IP address of your on-premises device is blocked by Security Center. To resolve the issue, add the public IP address of your on-premises device to the whitelist of Security Center. For more information, see the Method 3: Add a whitelist entry in Security Center 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 4: 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 by 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 by 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 liblz4.so.1.7.5 liblz4.so.1
```

Method 3: Add a whitelist entry in Security Center

If you enter an invalid password multiple times when you connect to the instance from an on-premises device, requests from the IP address of the on-premises device may be denied. You can add the IP address of the on-premises device to the whitelist of Security Center. This way, Security Center does not deny requests from the IP address. Perform the following steps:

Log on to the Security Center console.
In the left-side navigation pane, choose System Configuration > Feature Settings.
On the Settings tab, click the Other Settings tab. In the Security Control section, click Configuration to go to the Security Control console.
In the left-side navigation pane, choose Whitelist > Access Whitelist.
On the Access Whitelist page, click Add.
For more information, see the Security Control section of the "Enable features on the Other Settings tab" topic.

Method 4: 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.