Failure: nobody can log in, and sudo stopped working

“I cannot log in” is reported identically for four unrelated failures, and the wrong first move - changing a password, restarting sshd, rebooting - fixes none of them and destroys the evidence for all of them.

The four layers, in the order the system evaluates them:

The first three commands

Run these on the server, in this order, before touching anything. Between them they place the failure in one of the four layers.

$ getent passwd ada; id ada; journalctl -u ssh -u sshd --since '15 min ago' --no-pager | tail -20

ada:x:4021:4021:Ada Lovelace:/home/ada:/bin/bash
uid=4021(ada) gid=4021(ada) groups=4021(ada),27(sudo)
Aug 11 09:41:02 web02 sshd[8812]: Accepted publickey for ada from 192.0.2.55 port 51422 ssh2: RSA SHA256:REDACTED
Aug 11 09:41:02 web02 sshd[8812]: pam_unix(sshd:session): session opened for user ada(uid=4021)
Aug 11 09:41:03 web02 sshd[8812]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Three specific readings of that output:

• getent passwd returns nothing: the host does not know the account exists. Everything after this is irrelevant - go to resolution.
• getent works, and the journal shows Failed password or Invalid user: authentication.
• getent works, authentication succeeded, and the failure is after Accepted: authorisation or session.

Resolution: the directory went away

The signature is unmistakable once you know it: some people can log in and some cannot, and it correlates with who logged in recently.

That is a cache. With sssd, accounts that have authenticated before are cached and keep working while the directory is unreachable; everybody else stops existing.

$ getent passwd ada; getent -s files passwd ada; systemctl is-active sssd; journalctl -u sssd --since '1 hour ago' --no-pager | tail -10

active
Aug 11 09:12:41 web02 sssd_be[1442]: Backend is offline
Aug 11 09:12:41 web02 sssd[1440]: Domain example.com is Offline

Once you have that, the investigation moves off the host: the directory servers, the network path to them, DNS for their service records, and - very often - the certificate on the LDAP endpoint, which is a dated object that expires without anybody changing anything.

Clock skew belongs here too. Kerberos rejects authentication outright when host and KDC clocks differ by more than a few minutes, so a host whose time sync broke last week can present as an authentication failure for every domain account on it.

$ timedatectl; chronyc tracking | head -4

               Local time: Tue 2026-08-11 09:44:02 UTC
System clock synchronized: no
            NTP service: active
Reference ID    : 00000000 ()
Stratum         : 0
System time     : 412.882119 seconds slow of NTP time

Authentication: the credential, the account, or the lock

$ passwd -S ada; chage -l ada | head -5; faillock --user ada

ada P 07/14/2026 0 99999 7 -1
Last password change					: Jul 14, 2026
Password expires					: never
Account expires						: Aug 09, 2026
ada:
When                Type  Source                    Valid

passwd -S reports the password status: P for a usable password, L for locked, NP for no password at all. chage -l covers the aging and expiry dates. faillock --user lists recorded failures where pam_faillock is in use; a user locked out this way authenticates correctly and is still refused, and the lock clears on its own after the configured interval - which is why it is frequently reported as intermittent.

Key-based SSH has its own quiet failure: the daemon refuses keys from a directory that other users can write to, and says so only in its own log.

$ ls -ld /home/ada /home/ada/.ssh /home/ada/.ssh/authorized_keys; sshd -T | grep -iE 'strictmodes|authorizedkeysfile|pubkeyauthentication|allowgroups'

drwxr-xr-x 5 ada  ada  4096 Aug 11 09:40 /home/ada
drwxrwxr-x 2 ada  ada  4096 Aug 11 09:40 /home/ada/.ssh
-rw-r--r-- 1 root root  743 Aug 11 09:40 /home/ada/.ssh/authorized_keys
pubkeyauthentication yes
strictmodes yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2
allowgroups sudo ops

Authorisation: sudo stops working for everybody at once

A sudoers file that does not parse is not partially broken. sudo refuses to run at all, for every user, including the ones whose rules are unaffected.

$ visudo -c; sudo -l -U ada

/etc/sudoers:42:11: syntax error
%ops ALL=(ALL:ALL) NOPASWD: /usr/bin/systemctl
        ^~~~~~~~
sudo: parse error in /etc/sudoers near line 42

The other authorisation failure has no error message at all: group membership. AllowGroups in sshd_config and a sudoers rule keyed on %ops both stop applying the moment a user is removed from the group, and a directory that resolves the user but returns a stale or empty group list produces the same effect while every credential remains valid.

$ id -nG ada; getent group ops sudo

ada
ops:x:5001:bob,carol
sudo:x:27:root

Session: authenticated, and still not in

A login that reports success and then closes is a session failure. The common causes are dull and quick to check.

1. Home directory missing or not writable - check the mount, especially if home directories are on NFS
2. A full filesystem: no session can be written, so logins fail on a host whose shell prompt would have told you immediately
3. An invalid login shell in the passwd entry, or a shell that is not listed in /etc/shells where that is enforced
4. pam_systemd unable to reach logind, which appears as Failed to create session
5. SELinux or AppArmor denying the session transition, which is logged by the security subsystem and nowhere else

$ df -h / /var /home; df -i / /var /home; systemctl is-active systemd-logind

Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root   20G   20G     0 100% /
/dev/mapper/vg0-var    40G   12G   26G  32% /var
Filesystem       Inodes  IUsed IFree IUse% Mounted on
/dev/mapper/vg0-root 1.3M   214K  1.1M   17% /
active

Which subsystem it usually is not

The three things people reach for first are almost never the cause:

• Not the password. Resetting it fixes nothing when the account expired, the directory is offline, the group membership is gone or the filesystem is full - and it destroys the evidence of which of those it was.
• Not sshd’s ciphers or its configuration file. If sshd were misconfigured, nobody would be logging in, and the fleet would have failed at the same instant. A failure affecting some accounts and not others is above sshd, in the identity or authorisation layer.
• Not the network. The connection reached the server: you are reading the server journal entries it produced. A network fault does not generate Accepted publickey.

Knowledge check