What do I do if the "error while loading shared libraries" error message appears when I start the SSH service on a Linux ECS instance? - Elastic Compute Service

This topic describes the solutions to the issue that the "error while loading shared libraries" error message appears when you start the SSH service on a Linux Elastic Compute Service (ECS) instance.

Problem description

When you start the SSH service on a Linux ECS instance, an error message similar to the following one appears:

error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory.

When you run the cat /var/log/secure command to view secure logs, an error message similar to the following one appears:

PAM unable to dlopen(/usr/lib64/security/pam_tally.so): /usr/lib64/security/pam_tally.so: cannot open shared object file: No such file or directory.

Cause

The SSH service relies on specific system library files to run. If exceptions occurred in the system library files, such as when the system library files become unavailable or the permissions on the system library files are incorrectly configured, the SSH service cannot start.

Solutions

Restore the libcrypto.so.10 library file or roll back the system disk to resolve the issue.

Solution 1: Restore the libcrypto.so.10 library file

You can restore the library file of the faulty instance based on the library file information of a healthy instance.

Log on to the healthy instance and run the following command to view information about the libcrypto.so.10 library file:
```
ll /usr/lib64/libcrypto.so.10
```
A command output similar to the following one is returned, which indicates that the libcrypto.so.10 library file is the symbolic link to the libcrypto.so.1.0.1e library file.
```
lrwxrwxrwx. 1 root root 19 Jan 8 12:40 /usr/lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e
```
Run the following command to view information about the libcrypto.so.1.0.1e library file:
```
ll /usr/lib64/libcrypto.so.1.0.1e
```
Sample output:
```
-rwxr-xr-x. 1 root root 1965856 Jan 8 03:22 /usr/lib64/libcrypto.so.1.0.1e
```
Make note of the directory, permission, and group information of the library file in the healthy instance.
Connect to the faulty instance by using Virtual Network Computing (VNC).
For more information, see Connection method overview.
Run the following command to query the libcrypto.so.1.0.1e library file:
```
find / -name libcrypto.so.1.0.1e
```
Use one of the following methods to resolve the issue based on whether the libcrypto.so.1.0.1e library file exists:
- The libcrypto.so.1.0.1e library file exists.
  Run the following command to copy the library file to the same directory as the directory of the library file in the healthy instance:
```
cp [$File] /usr/lib64/libcrypto.so.1.0.1e
```
  Note
  Replace the [$File] variable with the absolute path of the libcrypto.so.1.0.1e library file that you found in the faulty instance.
- The libcrypto.so.1.0.1e library file does not exist.
  Use FTP to transfer the libcrypto.so.1.0.1e library file of the healthy instance to the /usr/lib64 directory of the faulty instance.
Run the following commands in sequence to change the permissions, owner, and group of the library file:
```
chmod 755 /usr/lib64/libcrypto.so.1.0.1e
chown root:root /usr/lib64/libcrypto.so.1.0.1e
```

Run the following command to create a symbolic link:

ln -s /usr/lib64/libcrypto.so.1.0.1e /usr/lib64/libcrypto.so.10

Run the following command to start the SSH service:
```
systemctl start sshd.service
```

Solution 2: Roll back the system disk of the faulty instance

If the issue cannot be resolved by performing the steps in Solution 1: Restore the libcrypto.so.10 library file and the system disk of the faulty instance has snapshots, you can roll back the system disk of the faulty instance by using a snapshot. For more information, see Roll back a disk by using a snapshot.

Important

After you roll back a disk by using a snapshot, all data changes that were made from when the snapshot was created to when the disk was rolled back are lost. Exercise caution when you perform the rollback operation.
We recommend that you select snapshots in reverse chronological order to roll back the system disk until the SSH service can run as expected. If the SSH service fails to start after you use a snapshot to roll back the system disk, an exception occurred at the point in time when the snapshot was created. You can use an earlier snapshot to roll back the system disk.