Does an expired password block SSH public-key login on openSUSE Leap?

Answer to the question

On a default openSUSE Leap 15.x installation, an expired password (i.e., the password has reached its maximum age and requires a change on the next password‑based login) does not block SSH public‑key authentication. The session will succeed as long as the key is valid and the account is otherwise enabled.

Confirmed facts (based on Leap’s default PAM/sshd stack)

• SSHD runs UsePAM yes by default, so the PAM account phase (pam_unix in /etc/pam.d/sshd) is invoked for every login, including public‑key sessions.
• The PAM pam_unix module checks the shadow file’s maximum age field (shadow field #5). If the password is expired, the module only forces a password change when the user supplies a password; it does not deny the session outright.
• Hard account expiry (the chage -E date, shadow field #8) is enforced by the same PAM account module and will cause a denial of login regardless of authentication method.
• The inactivity lock (shadow field #7, set via chage -I) behaves like password expiry: it only affects password authentication and does not block key‑based logins.
• When accounts are backed by SSSD or LDAP, local /etc/shadow aging is bypassed; expiry is enforced by the directory backend (e.g., LDAP password‑policy overlay or AD accountExpires).

Practical steps to verify on your system

1. Check that SSH is using PAM:

   sshd -T | grep -i usepam
   # Expected output: usepam yes
   

2. Create a test user and set a password that is already expired:

   sudo useradd -m testuser
   sudo passwd testuser
   # set password to a known value
   sudo chage -d 0 testuser   # force expiry
   

3. Generate or copy an SSH key for testuser and add it to ~testuser/.ssh/authorized_keys.

4. Attempt a key‑based login from another host:

   ssh -i ~/.ssh/id_rsa testuser@host
   # You should be logged in without a password prompt.
   

5. Now set a hard account expiry in the past:

   sudo chage -E 1 testuser   # 1 Jan 1970
   

6. Retry the key login:

   ssh -i ~/.ssh/id_rsa testuser@host
   # The connection should be refused; check logs:
   journalctl -u sshd | grep testuser
   

What to do if you need to disable a key‑based account

• Use chage -E or usermod -L to lock the account; this will block all authentication methods.
• For directory‑backed accounts, configure the password‑policy or account‑expiry attribute in the directory service itself.
• Optionally, set PermitEmptyPasswords no in /etc/ssh/sshd_config to prevent login when the password field is empty.

Missing diagnostic detail that could change the recommendation

Does your system use a custom PAM stack that disables pam_unix during the account phase? If so, key‑based logins may behave differently. Check /etc/pam.d/sshd for any overrides.