Failed to remotely connect to a Linux instance due to SSH permission errors-阿里云帮助中心

If you cannot remotely log on to a Linux instance because of abnormal Secure Shell Protocol (SSH) access permission settings, you can use the instance health diagnostics tool to fix the problem.

Prerequisites

The Linux instance has been diagnosed by the instance health diagnostics tool, and the diagnosis report indicates that the following checks failed:

Permissions on critical system files in the instance startup failure scenario.
SSH access permissions in the instance startup failure scenario.

Background information

Problem description: You cannot log on to a Linux instance over SSH because the access permissions for files and directories related to user passwords and SSH are abnormal.

Cause: The access permissions for files and directories related to user passwords and SSH on the Linux instance are insufficient.

This topic describes how to use a temporary repair disk from the instance health diagnostics tool to fix the instance. Alternatively, you can attach the system disk of the abnormal instance to a functioning instance for troubleshooting. For more information, see Failed to remotely connect to a Linux instance due to SSH permission errors.

Solutions

Connect to the abnormal instance.
A repair disk is attached to the instance, and you can connect to the instance only by using Virtual Network Console (VNC). For more information, see Connect to an instance using VNC.
View the mount information of the original system disk on the faulty ECS instance.
On the repair disk that is temporarily attached to the ECS instance, the file systems of the original system disk of the instance are mounted to a temporary directory. You can use one of the following methods to view the temporary directory:
- In the Associated Instances section on the disk details page of the original system disk, view the temporary directory. Example: /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****. bp19bspzms79kqse**** is the serial number of the original system disk of the ECS instance.
- Run the mount command on the repair disk to view the temporary directory. For example, if the device name of the original system disk of the faulty ECS instance is /dev/vda, run the following command:
```
mount | grep /dev/vda
```
  The following command output is returned:
```
/dev/vda1 on /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse**** type ext4 (rw,relatime)
```
To change the root directory to the temporary directory where the original system disk of the instance resides and enter the chroot environment, run the chroot command.
You must go to the temporary directory where the original system disk resides to restore configuration files. For example, if the temporary directory is /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****, run the following command:
```
chroot /tmp/ecs-offline-diagnose_disk-bp19bspzms79kqse****
```
In the chroot environment, run the following command to reset the permissions for the /var/empty/sshd directory.
Warning
- Set the permissions for this directory to match the permissions on a directory of another instance that runs the same Linux distribution and allows remote access. This helps prevent the SSH service from failing to start because of excessive permissions. Permissions on SSH-related files and directories are critical for protecting sensitive information, such as account names and passwords for remote connections. The SSH process has strict constraints on these permissions. If the permissions for a file or directory exceed the SSH constraints, the SSH service considers its content untrustworthy, which may cause the SSH service to fail to start or result in connection errors.
- Permissions set to 777 grant all users read, write, and execute permissions on a file or directory. This poses a high security risk. For example, if you set the permissions for the /var/empty/sshd directory to 777, any user can create, delete, or modify files in the directory. Do not set permissions to 777 unless you have a specific reason.
```
chmod 711 /var/empty/sshd
```
In addition to checking the permissions for the /var/empty/sshd directory, you can also use this solution to check the permissions for the /etc/passwd, /etc/group, /etc/shadow, and /etc/gshadow files, and the /etc/securetty directory. For the correct permissions, refer to the permissions on another instance that allows remote logon.
After the files are restored, exit the chroot environment and check the state of the abnormal instance.
1. Run the exit command to exit the chroot environment.
2. Go to the Troubleshooting page in the ECS console. On the Instance Health Diagnosis tab, detach the repair disk from the instance and start the instance.
3. Connect to the instance and confirm that you are connected to the instance.