SSH authentication failed because the password you entered is incorrect, or the user account doesn't have password authentication enabled. Common causes include wrong credentials, disabled password auth, or account restrictions.
This error appears in the SSH server logs (/var/log/auth.log or /var/log/secure) when someone attempts to log in with a password that doesn't match the stored credentials. Unlike "Failed password for invalid user", this message indicates the username exists but the password is wrong—or the account has restrictions preventing password-based login. The sshd daemon logs all authentication attempts for security auditing. This message is normal during: - Legitimate failed login attempts (typos, wrong user account) - Brute force attacks from remote hosts - Misconfigured authentication settings on the server
Double-check your credentials. This is the most common cause. Ensure you:
- Use the correct username (not an email address unless that's the actual username)
- Type the password correctly (watch for caps lock)
- Have the right password for the correct user account
# Attempt login with explicit username
ssh username@hostname
# Or with a specific port if SSH runs on a non-standard port
ssh -p 2222 username@hostnameSSH password entry is completely silent—no asterisks appear as you type, so it's easy to make typos.
If you have access to the server, verify PasswordAuthentication is enabled:
# Check the SSH server configuration
grep '^PasswordAuthentication' /etc/ssh/sshd_configIf it shows PasswordAuthentication no, password login is disabled. To enable it:
# Edit the SSH config (as root)
sudo nano /etc/ssh/sshd_config
# Find and change this line:
# PasswordAuthentication no
# To:
PasswordAuthentication yes
# Save and exit (Ctrl+X, Y, Enter in nano)
# Restart SSH service
sudo systemctl restart sshdIf you don't have server access, ask your system administrator to enable it.
Check if the user account has login restrictions:
# As root on the server, check account status
sudo chage -l usernameCheck for:
- Account locked (if output shows "Account locked")
- Password expired
- Account expiration date in the past
If the account is locked:
# Unlock the account
sudo passwd -u usernameAlso verify the user's shell is not a login shell:
# Check the shell assigned to the user
grep '^username:' /etc/passwd
# If the shell ends with /false or /nologin, change it:
sudo usermod --shell /bin/bash usernameSSH may have access control lists that block specific users:
# Check for user/group restrictions
grep -E '^(Allow|Deny)' /etc/ssh/sshd_configIf you see:
- AllowUsers user1 user2 - only those users can login
- AllowGroups groupname - only members of that group can login
- DenyUsers username - that user is explicitly blocked
Add your user to the allowed list:
# Edit the SSH config
sudo nano /etc/ssh/sshd_config
# Add or modify the line:
AllowUsers username
# Or add user to an allowed group:
sudo usermod -a -G sshlogin username
# Update the config:
AllowGroups sshlogin
# Restart SSH
sudo systemctl restart sshdUse SSH verbose mode to see exactly where authentication fails:
# Enable maximum verbosity (3 levels)
ssh -vvv username@hostname
# Or for a specific port:
ssh -vvv -p 2222 username@hostnameLook for output like:
- debug1: Authentications that can continue: password - password auth is available
- debug1: Offering password auth - client is sending password
- Authentications that can continue: ... but no "password" - auth method not available
This output helps you identify where the handshake breaks.
If basic troubleshooting doesn't work, examine the server logs:
# On Linux/Unix servers, check authentication logs
sudo tail -50 /var/log/auth.log # Debian/Ubuntu
# Or
sudo tail -50 /var/log/secure # RHEL/CentOS/Fedora
# Look for these patterns:
# - "pam_unix(sshd:auth): authentication failure; ..."
# - "pam: Authentication failure for [user]"
# - "Invalid user [username]" (username doesn't exist)These logs reveal whether the failure is password-based or caused by PAM, account restrictions, or other issues.
Repeated failed passwords can indicate brute force attacks. Install fail2ban to block offending IPs:
# Install fail2ban (Debian/Ubuntu)
sudo apt-get install fail2ban
# Or on RHEL/CentOS:
sudo yum install fail2ban
# Start the service
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
# Monitor blocked IPs
sudo fail2ban-client status sshdFor production servers, also consider:
- Disabling password authentication entirely in favor of SSH keys
- Running SSH on a non-standard port
- Using security groups/firewalls to restrict SSH access to known IPs
Windows OpenSSH Note: On Windows 10/11 with OpenSSH, you must use your online password, not your Windows PIN. If you see "LookupAccountName() failed: 1332" in debug output, this indicates the account mapping failed—ensure you're using the correct account name format (domain\\username for domain accounts).
LDAP/Active Directory: If your organization uses centralized authentication, the password may be correct locally but rejected by the LDAP/AD server. Contact your IT department to verify account status in the directory.
Security Hardening: In production environments, disable password authentication entirely and use SSH keys instead. This eliminates password guessing attacks:
# In /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yesLoad key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH