This bug is a consequence of the fix applied in bug 789. When using keyboard-interactive to login through OpenSSH to a Solaris 8 NIS+/PAM host, the automatic 'keylogin' feature of the pam_dhkeys PAM module disappears. It's not so bad; the workaround is to run keylogin manually once at a shell. debug3: PAM: opening session debug1: PAM: reinitializing credentials The cause seems to be that the pam_dhkeys.so module ignores the PAM_REINITIALIZE_CRED flag passed by OpenSSH to pam_setcred(). If I make it pass PAM_ESTABLISH_CRED instead, then it works fine. The PAM_REINITIALIZE_CRED feature was added to fix when initgroups() stomped on when pam_setcred() had already been called from early on in do_exec_[no]_pty(): date: 2001-03-27 16:12:24 +1000; author: djm; state: Exp; lines: +4 -3; - (djm) Reestablish PAM credentials (which can be supplemental group memberships) after initgroups() blows them away. Report and suggested fix from Nalin Dahyabhai <nalin@redhat.com> But, the early call to pam_setcred() was later disabled in bug 789 to make linux pam_group.so work. There seems to be much confusion over the purpose of pam_setcred(), but I think it is safe to say that openssh should call setcred(ESTABLISH) instead of setcred(REINITIALIZE) if setcred(ESTABLISH) has never been called before.
Created attachment 1326 [details] ensure do_pam_setcred(1) is called at least once
$ gcc [options] session.c session.c: In function 'do_setusercontext': session.c:1355: error: 'privsep' undeclared (first use in this function) session.c:1355: error: (Each undeclared identifier is reported only once session.c:1355: error: for each function it appears in.) Trivially fixable, of course, but it makes me wonder how much testing it's seen :-)
OK I've look at it and tested it a little and I think it's probably the correct thing to do, at least for now. Patch applied, thanks (it will be in 4.7).
Close resolved bugs after release.