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.

Also: please try commenting out pam_ldap as a session module and see if the
behaviour changes.

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 type=
password    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.

(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?

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?

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. 

* 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.

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.

(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.

Please also see bug #511.

Created attachment 1036 [details]
Debugging output of the issue

Finally, here is the output of sshd -ddd. First, in normal operation. Second, when the problem occurs. Third, with an expired password, and disabling public key authentication.

Comment on attachment 1036 [details]
Debugging output of the issue

This looks like the reason:
>PAM: pam_chauthtok(): User not known to the underlying authentication module

I suspect that the chauthtok() in the pam_ldap module relies on something set earlier during the authenticate(), and is bailing when it's not present due to the authentication being done via public-key and not PAM.  If that's the case, I can't see anything sshd can do to make pam_chauthtok() work under those conditions, it would require (probably minor) surgery on pam_ldap.

As a workaround you can try enabling UsePrivilegeSeparation: this will cause sshd to exec /usr/bin/password to change the password, rather than using pam_chauthtok() directly.

There exists a description + workaround for the problem in HP-UX at http://docs.hp.com/en/6965/pam_authz_for_policy_wp_2_3.pdf .

Thanks a lot, things indeed work with privilege separation enabled.
(Privilege separation didn't work with LDAP in OpenSSH 3.6, that's why we had disabled it.)

Cool.  Like I said, I don't think there's anything that sshd can do in the pam_chauthtok() case and you'd need to modify pam_ldap to make it work.

Closing bug.

Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.

looks like this bug should have been closed 14 years ago :)

close bugs that were resolved in OpenSSH 8.5 release cycle