How do I resolve the 'Access denied' error when logging on to a Linux instance using a third-party SSH client? -

Problem Description

Remote logon failed: When you connect to a Linux instance by using a third-party Secure Shell (SSH) client, such as PuTTY, XShell, or SecureCRT, the connection fails with an Access denied or Permission denied, please try again. error.
System security log: The system log file /var/log/secure contains messages such as not allowed because.

Cause

By default, the SSH service on a Linux instance lets any system user log on with their credentials (a password or a key). If logon restriction policies are enabled in the SSH service configuration file /etc/ssh/sshd_config, incorrect configurations can prevent specific users from logging on to the instance.

AllowUsers: A user whitelist. Only users in the list can log on.
DenyUsers: A user blacklist. Users in the list are denied logon access.
AllowGroups: A user group whitelist. Only users in the listed groups can log on.
DenyGroups: A user group blacklist. Users in the listed groups are denied logon access.

Deny policies (Deny*) have a higher priority than allow policies (Allow*). If a user matches both an allow policy and a deny policy, access is denied.

Solution

Log on to an ECS instance using a VNC connection.
1. Go to ECS console - Instances. In the top navigation bar, select the target region and resource group.
2. Go to the details page of the target instance. Click Connect and select VNC. Enter the username and password to log on to the ECS instance.
Check and modify the SSH configuration file.
1. Back up the configuration file so that you can restore it if an error occurs.
```
sudo cp /etc/ssh/sshd_config  /etc/ssh/sshd_config.bak
```
2. Locate and adjust the access control policies.
```
sudo vi /etc/ssh/sshd_config
```
  Modify the file in one of the following ways:
  - Method 1: Comment out all restriction rules
    To remove logon restrictions, comment out the AllowUsers, DenyUsers, AllowGroups, and DenyGroups parameters by adding a # symbol at the beginning of each line. This lets all system users log on.
```
# AllowUsers userA userB
# DenyUsers userC
```
  - Method 2: Correct the restriction rules
    To ensure your policies are unambiguous, avoid using whitelist (Allow*) and blacklist (Deny*) rules simultaneously.
    - Use a whitelist policy (for scenarios where only a few specific users are allowed to log on)
      Keep only the AllowUsers or AllowGroups parameter. Add the users or user groups that require logon access to the list. Then, comment out or delete all Deny* parameters.
```
 AllowUsers userA userB newUser
 # DenyUsers userC 
```
      This example lets only users userA, userB, and newUser log on, and denies access to all other users.
    - Use a blacklist policy (for scenarios where only a few specific users must be denied logon access)
      Keep only the DenyUsers or DenyGroups parameter. Add the users or user groups that you want to block to the list. Then, comment out or delete all Allow* parameters.
```
# AllowUsers userA userB
 DenyUsers userC userD
```
      This example denies access to users userC and userD, while allowing all other users to log on.
Restart the SSH service to apply the new configuration.
```
sudo systemctl restart sshd.service
```
If the service fails to start, run the cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config command to restore the configuration file from the backup.
Try logging on to the instance again with your third-party SSH client to confirm the issue is resolved.