When encountering "Permission denied" errors in SSH despite having correct credentials, we need to examine the complete authentication chain. From your debug output (sshd -d), we can see the authentication attempts:

debug1: userauth-request for user skerit service ssh-connection method none
debug1: attempt 0 failures 0
debug1: userauth-request for user skerit service ssh-connection method publickey
debug1: attempt 1 failures 0
debug1: userauth-request for user skerit service ssh-connection method password
debug1: attempt 2 failures 1
debug1: PAM: password authentication failed for skerit: Authentication failure

Your sshd_config shows password authentication is enabled, but PAM might be interfering:

PasswordAuthentication yes
UsePAM yes

Check these critical settings:

• Ensure SELinux isn't blocking access: getenforce
• Verify PAM configuration: /etc/pam.d/sshd
• Check user's shell in /etc/passwd

The debug output shows PAM authentication failure despite local login working. Possible causes:

# Sample PAM configuration that might cause issues:
auth required pam_listfile.so item=user sense=deny file=/etc/ssh/deniedusers onerr=succeed
auth required pam_unix.so

Try temporarily disabling PAM to test:

# In /etc/ssh/sshd_config
UsePAM no

SSH is extremely particular about file permissions. Verify:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts

Check for these potential network-related blocks:

# iptables rules might block certain authentication methods
iptables -L -n -v

# TCP wrappers configuration
cat /etc/hosts.allow
cat /etc/hosts.deny

Client-side debugging with -vvv can reveal more:

ssh -vvv user@hostname

Server-side debug mode helps identify the exact failure point:

/usr/sbin/sshd -d -p 2222

If password authentication continues to fail, consider:

1. Generating new SSH keys: ssh-keygen -t ed25519
2. Testing with a new user account
3. Checking disk space and inodes
4. Verifying system logs: journalctl -u sshd -f

---

When facing SSH password authentication failures while public key authentication works, the root cause often lies in PAM (Pluggable Authentication Modules) configuration. The debug output shows this critical line:

debug1: PAM: password authentication failed for skerit: Authentication failure

This indicates the system's PAM stack is rejecting the credentials, even though they work for local logins. Let's examine the key configuration files:

First, verify the PAM configuration for SSH:

# /etc/pam.d/sshd (common issues)
auth    required    pam_unix.so     try_first_pass nullok
account required    pam_unix.so

Check for any restrictive settings like pam_listfile.so or pam_access.so that might block remote attempts.

Running the SSH daemon in debug mode provides crucial insights. From your output:

/usr/sbin/sshd -d -p 2222  # Test on alternate port

The debug output reveals the authentication sequence:

debug1: attempt 2 failures 1
debug1: PAM: password authentication failed for skerit: Authentication failure

Even with correct sshd_config, these elements often block access:

# Check SELinux context
ls -Z /home/skerit/.ssh/authorized_keys

# Correct permissions (critical)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R user:user ~/.ssh

Directly test PAM authentication:

# Test authentication through PAM
sudo pam-auth-update  # Check active PAM profiles
pamtester sshd skerit authenticate

Examine these potential network-level blocks:

# Check TCP wrappers
cat /etc/hosts.deny
cat /etc/hosts.allow

# Firewall rules (example for UFW)
sudo ufw status numbered

For persistent issues, enable deeper logging:

# In /etc/ssh/sshd_config
LogLevel DEBUG3

# PAM debugging (add to /etc/pam.d/sshd)
auth    debug    pam_unix.so

Verify the password works outside SSH:

# Local password verification
su - skerit  # Then enter password
# OR
echo 'password' | su - skerit -c 'whoami'

Key settings to review in sshd_config:

# Ensure these are set
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
AuthenticationMethods publickey,password