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

Password expiry versus account expiry during key-based SSH sessions

On openSUSE Leap 15.x, the shadow suite stores password aging in /etc/shadow, managed through chage or YaST. Two mechanisms are easy to conflate: password expiry past the maximum age, which normally forces an immediate change at the next login via PAM, and a hard account expiry date, which blocks login outright. A third state, the inactivity lock that disables the password after the post-expiry grace period, adds further ambiguity.

The unresolved case is key-based SSH. With public-key authentication no password is ever presented, so it is unclear whether an expired password blocks the session, allows it silently, or triggers a forced-change flow that may not even be possible without password authentication. Behavior reportedly depends on sshd's UsePAM setting and the account checks in the PAM stack, and defaults may differ between Leap and Tumbleweed. Accounts backed by SSSD or LDAP bypass local shadow aging entirely, moving enforcement to the identity backend.

Assuming a default Leap 15.x install with a PAM-enabled sshd configuration:

• Does an expired password (past maximum age) permit or deny SSH public-key login?
• Does the inactivity lock behave differently from account expiry for key-based sessions?
• Where should expiry policy live when accounts come from a directory service instead of local shadow?