WARNING: Your password has expired. Password change required but no TTY available. rsync: connection unexpectedly closed (0 bytes received so far) [sender] The problem: No password was being used. I contend that certificate-based authentication should still be allowed if the password has expired. The fact that a password has expired does not mean that the account has been compromised and that RSA keys should not be trusted; it simply means that the aged password should not be used any more. Locking out an authorized key because a password has expired makes about as much sense to me as locking out every other key in authorized_keys because one of them is revoked.
What platform are you using on the server? Is PAM enabled?
Just checked using Debian 6.0 and default setup, which does have PAM enabled. Created a new blank account, checked that certificate-based authentication worked, and then expired the password and tried to run an rsync session: $ rsync -av -e 'ssh -l sshtest' haddock.txt castor.local:. WARNING: Your password has expired. Password change required but no TTY available. rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7] From the logs, it looks as if pam_unix is always activated by sshd, even if Unix password authentication is not being used: <38>1 2011-06-24T15:09:23.691311-05:00 castor sshd 25622 - - Accepted publickey for sshtest from 10.0.1.200 port 45366 ssh2 <86>1 2011-06-24T15:09:23.692556-05:00 castor sshd 25622 - - pam_unix(sshd:session): session opened for user sshtest by (uid=0) pam.d/sshd loads directives from common-password common-account common-session and common-auth, so I grepped for pam_unix: common-password:password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512 common-account:account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so common-session:session required pam_unix.so common-auth:auth [success=1 default=ignore] pam_unix.so nullok_secure I tried changing common-session to say 'sufficient pam_unix.so' instead of required, restarted sshd, but it didn't seem to make any difference.
I think using pam_unix.so in the account stack is the culprit. Commenting it out would probably fix your key login problems, but would allow accounts with expired passwords to authenticate using passwords. We don't have a good solution for this yet, though some have suggested using different PAM service names for different authentication methods.
6 years with no followup == no bug
% rsync -av tmp/keepgif.png castor.local:. Enter passphrase for key '/home/meta/.ssh/id_rsa': Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 1 WARNING: Your password has expired. Password change required but no TTY available. rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.2] % i.e. still does it.
Ok, so back in 2011 I pointed out that the pam_unix in your account stack is likely the problem. Did you check this before reopening the bug?
Actually pam_unix from Linux-PAM 1.3.0 supports a new option 'no_pass_expiry' which will make it work for you. This option causes skipping password expiration checks if pam_authenticate was not called.
Thanks. Sadly I'm running Debian, so it'll be another few years before I get linux-pam 1.3. (Current version is 1.1.8.) But, the key thing is there's a fix and now it's documented to find in future. :-)
Close all resolved bugs after release of OpenSSH 7.7.