PAM password expiration behavior during non-interactive SSH sessions

Direct answer

pam_expire is not TTY-aware. It runs in the PAM account phase and returns PAM_NEW_AUTHTOK_REQD when /etc/shadow aging fields require a password change. The application—here, sshd—must decide what to do with that status. With OpenSSH compiled with PAM support and UsePAM yes, a non-interactive SFTP or SCP session that receives PAM_NEW_AUTHTOK_REQD is treated as a failed authentication, not as a successful login. A missing TTY does not turn that return code into success; it simply means sshd cannot satisfy the requirement by prompting.

Confirmed facts and likely explanation

The confirmed behavior is that pam_expire signals aging in the account phase and that sshd's PAM path enforces it when PAM is active. The likely explanation for observed variation is not TTY detection inside PAM, but differences in the local PAM stack and sshd configuration:

• If /etc/pam.d/sshd (or an included file) omits an account-phase pam_unix.so or pam_expire.so check, an expired password may never produce PAM_NEW_AUTHTOK_REQD for that connection.
• If the check uses optional or sufficient control flags, or a bypass rule precedes it, the expiration can be non-fatal even when the module exists.
• If sshd runs with UsePAM no, it may perform its own shadow checks and never invoke pam_expire, changing the decision point entirely.

Distribution and stack differences

Debian and Ubuntu systems typically assemble the sshd account stack through pam-auth-update includes such as common-account. RHEL-family distributions commonly include password-auth or system-auth. In both cases, whether pam_expire.so is present, whether pam_unix.so is marked required or requisite, and whether a management tool has rewritten the files are local configuration choices. These choices—not the presence of a TTY—explain most cross-distro inconsistency.

Automated service accounts

Key-based authentication does not automatically bypass the PAM account phase when sshd runs PAM. If the service account's password is aged and the stack returns PAM_NEW_AUTHTOK_REQD, automation will fail. If your security policy requires expiration to invalidate all access paths, keep the account-phase check and expect non-interactive sessions to be denied. If policy permits an exception for that account, disable password aging for it explicitly and rely on key restrictions; do not weaken aging globally.

Verification steps

1. Inspect the sshd PAM stack and its includes for account-phase checks: grep -E '^account' /etc/pam.d/sshd. Then inspect any included files (for example, common-account or system-auth).
2. Confirm sshd is using PAM (run as root): sshd -T | grep -i usepam.
3. On a disposable account, distinguish password aging from account expiration or inactivity: chage -l testacct and passwd -S testacct.
4. Reproduce safely and capture the server-side result: force a change with chage -d 0 testacct, attempt sftp testacct@host and scp file testacct@host:, then inspect the log with journalctl -u sshd or /var/log/auth.log / /var/log/secure.

Diagnostic detail that changes the recommendation

If your stack already contains an account-phase check and UsePAM is enabled, the detail that determines the next step is the server-side log message: does the failed non-interactive attempt show PAM_NEW_AUTHTOK_REQD or a password-expiry message, or does the connection simply close with no PAM output? A PAM message means sshd is enforcing expiration and the decision is a policy exception for the service account. A silent close with no PAM message points to a missing or bypassed account-phase check in the stack.