Resolve

Problem description

When you connect to a Linux instance using SSH, the connection fails with the message Permission denied, please try again, even with the correct username and password.

Diagnose the problem

Log on to an ECS instance using a VNC connection.
1. Go to Simple Application Server console. 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 the SSH service configuration.

If PermitRootLogin or PasswordAuthentication is set to no, see Resolve "Permission denied, please try again" for root SSH login to resolve the issue.
- PermitRootLogin: When set to no, blocks root SSH login.
- PasswordAuthentication: When set to no, disables password-based login for all users.
```
sudo cat /etc/ssh/sshd_config
```
Check the system security logs.

SELinux may block login attempts and log errors in the system security log.

SELinux enforces Mandatory Access Control (MAC) rules that govern what each process can access.
```
# For CentOS/RHEL systems
sudo grep -iE --color=auto 'Could not get shadow information' /var/log/secure

# For Debian/Ubuntu systems
sudo grep -iE --color=auto 'Could not get shadow information' /var/log/auth.log
```
If the command returns no output, an SELinux policy is the likely cause. Refer to Resolve "Permission denied, please try again" for root SSH login.

Resolution

Use case 1: SSH configuration denies logon

Modify the configuration
```
sudo vi /etc/ssh/sshd_config
```
Adjust the parameters as needed:
- Allow password authentication: Change PasswordAuthentication no to PasswordAuthentication yes.
- Allow root user logon:
  - Allow key-based authentication (Recommended): To use a key pair for root logon, set PermitRootLogin to prohibit-password.
  - Allow password authentication: Change PermitRootLogin no to PermitRootLogin yes.
    
    Important
    Allowing root logon with a password (PermitRootLogin yes) increases the instance's exposure to brute-force attacks. We recommend that you use key-based authentication or restrict access by source IP address instead.
After you modify the file, press Esc, type :wq, and press Enter to save the file and exit.
Check the configuration and restart the service
1. Verify the syntax of the configuration file. No output indicates the syntax is correct.
```
sudo sshd -t
```
2. Restart the SSH service to apply the changes.
```
sudo systemctl restart sshd
```
Verify the connection

Connect to the instance again using SSH to verify that the issue is resolved.

Use case 2: SELinux policy blocks logon

Check the current status of SELinux

Check if SELinux is in enforcing mode.
```
sudo sestatus
```
If the output shows SELinux status as enabled and Current mode as enforcing, the SELinux policy is active.
Temporarily change the SELinux mode to restore access

Temporarily switch SELinux to Permissive mode. In this mode, SELinux logs warnings but does not block operations.
```
sudo setenforce 0
```
Important
This change is temporary and resets when the instance restarts.

After you run the command, try to log on again using SSH. A successful logon confirms that SELinux was causing the issue.
Permanently modify the SELinux configuration (Optional)
1. Modify the configuration file. Change the default mode of SELinux from enforcing to permissive.
```
sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
```
2. Restart the instance to apply the change.
Verify the connection

Connect to the instance again using SSH to verify the connection.