How to fix error: PAM: Authentication failure for user from hostname in SSH

Double-check that you are entering the correct username and password. Pay special attention to:

- Capitalization (usernames and passwords are case-sensitive)
- Special characters that may be interpreted differently on various keyboard layouts
- Spaces before or after the username

If you're using a special character like (, ), @, or #, try using a simpler password temporarily to isolate keyboard layout issues.

If you have physical or console access, try logging in locally at the terminal:

login
# Enter username and password

If local login succeeds but SSH fails, the issue is SSH/PAM configuration, not account status. If local login also fails, the account itself is likely disabled or password-related.

Check the SSH authentication logs for more detailed error messages:

On Debian/Ubuntu:

sudo tail -f /var/log/auth.log
# Look for lines with "sshd", "PAM", and the username

On RHEL/CentOS:

sudo tail -f /var/log/secure
# Look for lines with "sshd", "PAM", and the username

The logs may reveal the specific PAM module that failed (e.g., pam_unix, pam_sss, pam_ldap).

As root or with sudo, check the account status:

# Check if account is locked
sudo passwd -S username

# Check expiration date
sudo chage -l username

# Verify user shell is valid
sudo getent passwd username
# Look for the shell in /etc/shells
cat /etc/shells

If the account is locked (marked with LK or similar), unlock it:

sudo passwd -u username

If the shell is invalid, update it:

sudo usermod -s /bin/bash username

Review /etc/ssh/sshd_config for incompatible settings:

sudo grep -E "^(UsePAM|PasswordAuthentication|ChallengeResponseAuthentication|PermitRootLogin)\s" /etc/ssh/sshd_config

Ensure these are set appropriately:

UsePAM yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
# OR for key-only auth:
# PasswordAuthentication no

After making changes, validate and reload:

sudo sshd -t
sudo systemctl restart ssh  # or sshd

If you're using LDAP, Kerberos, or SSSD for authentication, check if the directory service is responding:

# Test LDAP connectivity (if using LDAP)
sudo ldapsearch -x -H ldap://ldapserver -D "cn=admin,dc=example,dc=com" -W

# Check SSSD status (if using SSSD)
sudo systemctl status sssd
sudo sssd -d 0x0fff  # Enable verbose logging

# Verify identity provider is working
getent passwd username
getent group groupname

If directory service is unreachable, resolve connectivity before attempting SSH login.