openssh bugs - Aug 2005 - [Bug 1065] password expiration and SSH keys don't go well together

http://bugzilla.mindrot.org/show_bug.cgi?id=1065

           Summary: password expiration and SSH keys don't go well together
           Product: Portable OpenSSH
           Version: 4.1p1
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: PAM support
        AssignedTo: bitbucket at mindrot.org
        ReportedBy: joss at debian.org


We are running a setup using pam_ldap, and password expiration. When a password
is expired, PAM forces the user to change it. However, here is what happens when
using a SSH key to log in without a password:

16:33 jmouette at silicium ~ > ssh tantale
You are required to change your LDAP password immediately.
Last login: Wed Aug  3 15:49:24 2005 from silicium.ccc.cea.fr
Connection to tantale closed.

When disabling the key, things work as expected:
16:38 jmouette at silicium ~ > ssh -o PubkeyAuthentication=no tantale
Password:
You are required to change your LDAP password immediately.
Enter login(LDAP) password:
New password:
Retype new password:
LDAP password information changed for jmouette
Last login: Wed Aug  3 16:33:27 2005 from silicium.ccc.cea.fr
[ successful login ]



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From dtucker at zip.com.au  2005-08-04 11:52 -------
pam_unix doesn't do that on my (FC3) system, it throws the user into a
password
change dialogue even with pubkey auth.

Could you please attach the relevant PAM conf file to this bug?

I would guess that pam_ldap is configured as a session module and that's
causing
the login to be dropped before the password can be changed.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From dtucker at zip.com.au  2005-08-04 11:57 -------
Also: please try commenting out pam_ldap as a session module and see if the
behaviour changes.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From joss at debian.org  2005-08-04 17:09 -------
Here is the PAM configuration (using RHEL 3.0, except for the pam_ldap module,
version 178, and the sshd daemon, version 4.1p1).

auth        required      /lib/security/$ISA/pam_env.so
auth [success=1 default=ignore] /lib/security/$ISA/pam_unix.so nullok_secure
auth        required      /usr/local/lib64/ldap/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_permit.so

account     sufficient    /usr/local/lib64/ldap/pam_ldap.so
account     required      /lib/security/$ISA/pam_unix.so

password    required      /lib/security/$ISA/pam_cracklib.so retry=3
typepassword    sufficient    /usr/local/lib64/ldap/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_unix.so nullok use_authtok md5
shadow

session     required      /lib/security/$ISA/pam_limits.so
#session     sufficient    /usr/local/lib64/ldap/pam_ldap.so use_authtok
session     required      /lib/security/$ISA/pam_unix.so

Commenting out the session pam_ldap stanza or uncommenting it doesn't change
the
behavior.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From dtucker at zip.com.au  2005-08-04 19:19 -------
(In reply to comment #3)
> Commenting out the session pam_ldap stanza or uncommenting it doesn't
change the
> behavior.
In that case my guess as to what's happening was wrong.  Could you please
attach
(ie use "create new attachment" rather than pasting into the comment
field) the
server side debugging from "/path/to/sshd -ddd" for both pubkey and
non-pubkey
logins?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From dtucker at zip.com.au  2005-08-04 19:22 -------
Also: is this built from vanilla source or a vendor-supplied binary?  If the
latter, can you reproduce the behaviour with vanilla openssh-4.1p1?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065


senthilkumar_sen at hotpop.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |senthilkumar_sen at hotpop.com




------- Additional Comments From senthilkumar_sen at hotpop.com  2005-08-10
16:55 -------
I think this problem have some resemblance with the discussion at http://marc.
theaimsgroup.com/?l=openssh-unix-dev&m=110844606628771&w=2. I feel the
change in
behaviour occurs if you comment pam_ldap from Account management section. I 
think the call pam_acct_mgmt() is returning PAM_NEW_AUTHTOK_REQD. 



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From joss at debian.org  2005-08-10 18:36 -------
* This is a local build of vanilla OpenSSH 4.1p1 sources.
* The machine is in production now, so I can't obtain the debugging output.
I
will try to obtain in during the next maintenance.
* Commenting out the account stanza leads to a different message ("You are
required to change your password immediately (password aged)" instead of
"You
are required to change your LDAP password immediately.") but the behavior
still
occurs.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From senthilkumar_sen at hotpop.com  2005-08-10
19:20 -------
That message happens because of pam_unix(local password aging). I suspect the 
problem as below, the pam_authenticate() is skipped in sshd for key based 
authentications. So when pam_acct_mgmt() is called at this case, I guess  
pam_ldap checks whether previous call for pam_authenticate() is successful or 
not (which is skipped). This may results in this kind of behaviour.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From dtucker at zip.com.au  2005-08-10 20:03 -------
(In reply to comment #7)
> * The machine is in production now, so I can't obtain the debugging
output. I
> will try to obtain in during the next maintenance.
If it's permitted by your policy, you can run sshd on a non-standard port on
the
loopback and get the debug trace that way ("/path/to/sshd -ddd -o
listenaddress=127.0.0.1:222")

Alternatively, if it would permit running some code as root that's not a
network
service then you could use my PAM test tool:
http://www.zip.com.au/~dtucker/patches/#pamtest

The "-a" option approximates what sshd does for public-key
authentications, and
the "-s" option lets you test alternate PAM service names without
affecting the
production ones.  It may give enough information to figure out what's going
on.
 Something like this ought to do it:
# ./pam-test-harness -s sshd -a -u youruser

Caveat: it does not implement an "echo off" so it will echo any
passwords to the
tty.  Remove anything sensitive before sending (and beware of shoulder-surfers
:-)

If neither of the above is the case then I'm out of options and we'll
wait for
the debug output.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=1065





------- Additional Comments From Ulrich.Windl at rz.uni-regensburg.de 
2005-08-18 18:41 -------
Please also see bug #511.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.