Authentication and User Errors
The 10 most common authentication errors come from PAM, sudo, SSH key permissions, and account lockout policies. Most aren’t password problems — they’re configuration mismatches between what the user typed and how the system expects credentials. This article covers the ten you’ll see most often, with description and fix.
#031 Authentication failure (PAM)
Description: Login fails with “auth.log” entry “authentication failure; logname= uid=0…”.
Solution: journalctl -u sshd or tail /var/log/auth.log; verify password isn’t expired with chage -l user; check /etc/nsswitch.conf; if using LDAP/SSSD, verify id user resolves.
#032 user is not in the sudoers file
Description: User runs sudo, gets “This incident will be reported.”
Solution: sudo visudo — never edit sudoers directly; or drop a file in /etc/sudoers.d/username: username ALL=(ALL) ALL; verify with sudo -l -U username.
#033 Permissions are too open (SSH key)
Description: SSH refuses an identity file: “UNPROTECTED PRIVATE KEY FILE!”
Solution: chmod 700 ~/.ssh; chmod 600 ~/.ssh/id_*; chmod 600 ~/.ssh/authorized_keys. Server-side too: chmod 600 /home/user/.ssh/authorized_keys; chown user:user.
#034 Account locked due to N failed logins
Description: User can’t log in after several attempts; pam_faillock kicked in.
Solution: faillock --user alice --reset; or wait for lockout window to expire; review /etc/security/faillock.conf for thresholds.
#035 sudo: a password is required (no tty)
Description: Cron or systemd job runs sudo but fails because no terminal is attached.
Solution: Add NOPASSWD for the specific command: username ALL=(ALL) NOPASSWD: /usr/local/bin/cmd; or remove requiretty from sudoers; or run the command without sudo (configure it to run as the right user via systemd User=).
#036 No matching key exchange method (ssh)
Description: SSH client and server can’t agree on a KEX algorithm. Common when connecting to ancient servers from new clients.
Solution: Temporary: ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@host; long-term: upgrade the server.
#037 user shell is /sbin/nologin
Description: Login succeeds at PAM level then immediately disconnects.
Solution: getent passwd user | cut -d: -f7 — if it’s /sbin/nologin, that’s by design (system account). Change with chsh -s /bin/bash user.
#038 stale group membership
Description: User added to a group but new permissions don’t take effect.
Solution: Group memberships are loaded at login time. User must log out and back in, OR use newgrp groupname to start a new shell with refreshed groups.
#039 incorrect password for sudo (3 strikes)
Description: User mistyped sudo password three times; sudo session is rejected.
Solution: sudo -k to clear the cached credential; retry with the right password. If genuinely forgotten, root must reset.
#040 SSH key passphrase prompt won’t accept
Description: Correct passphrase appears to fail.
Solution: Likely the wrong key being offered. ssh -vvv user@host 2>&1 | grep "Offering public key" shows what client tried; specify with -i ~/.ssh/specific-key.
Conclusion
Five habits:
journalctl -u sshd -fortail -F /var/log/auth.logwhile debugging logins.visudo -cafter every sudoers change — bad syntax locks out everyone.- SSH key permissions: directory 700, files 600. Always.
- Use
/etc/sudoers.d/drop-in files instead of editing the main sudoers. - For service accounts that need privileges, use systemd
User=+ capabilities, not sudo from cron.
Related Linux Admin articles
- Linux User & Service Management — the command reference for users / sudoers / systemctl
- Linux File Permissions — for the underlying chmod/chown model
- Linux Security Errors — for SELinux / AppArmor denials that masquerade as auth issues