openssh bugs - May 2011 - [Bug 1904] New: sshd refuses certificate-based authentication if password has expired

https://bugzilla.mindrot.org/show_bug.cgi?id=1904

           Summary: sshd refuses certificate-based authentication if
                    password has expired
           Product: Portable OpenSSH
           Version: 4.3p2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: meta at pobox.com


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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1904

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> 2011-06-10 12:10:17
EST ---
What platform are you using on the server? Is PAM enabled?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1904

--- Comment #2 from mathew <meta at pobox.com> 2011-06-25 06:23:07 EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1904

--- Comment #3 from Damien Miller <djm at mindrot.org> 2011-06-25 11:46:42
EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.