PAM password expiration behavior during non-interactive SSH sessions

Linux systems utilize the pam_unix and pam_expire modules to enforce password aging policies based on the /etc/shadow file. While these modules consistently force a password change during local TTY logins, the behavior varies when credentials expire for users connecting via non-interactive SSH sessions (e.g., SFTP or automated SCP transfers).

The goal is to maintain a least-privilege security posture where expired credentials immediately invalidate all access paths, regardless of the session type. However, there is uncertainty regarding how different PAM stack configurations handle the expiration trigger when no interactive shell is available to prompt the user for a new password.

Technical Questions

• Does pam_expire consistently deny access to non-interactive SSH sessions when a password has expired, or does it allow the session to proceed if no TTY is allocated?
• How does the interaction between pam_unix and pam_expire differ across common Linux distributions when handling expired credentials for automated service accounts?