openssh bugs - Sep 2003 - [Bug 688] keylogin not successful

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

           Summary: keylogin not successful
           Product: Portable OpenSSH
           Version: 3.7.1p1
          Platform: UltraSparc
        OS/Version: Solaris
            Status: NEW
          Severity: major
          Priority: P2
         Component: PAM support
        AssignedTo: openssh-bugs at mindrot.org
        ReportedBy: paul.a.bolton at bt.com


Tested on Solaris 8 HW02/02 SPARC fully patched with latest recommended set.

On 3.6.1p2 openssh would correctly authenticate via the PAM framework against
all modules. 3.7p1 and 3.7.1p1 logins do not successfully perform a keylogin via
the pam_dhkeys.so.1 module.

This results in the users not having correctly set creds in the keyserv and
therefore cannot authenticate against "sec=dh" shares or other
services
requiring DH authentication.



------- 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=688





------- Additional Comments From paul.a.bolton at bt.com  2003-09-19 20:23
-------
Created an attachment (id=434)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=434&action=view)
pam_dhkeys debug option

This shows that the module is not finding any keys from NIS+.



------- 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=688





------- Additional Comments From paul.a.bolton at bt.com  2003-09-22 01:09
-------
After looking at the problem today, I believe I have found the source of the
problem.

auth-pam.c spawns processes in order to perform the authentication and
credential setting in sub-processes. The workaround I have used is to force the
use of USE_POSIX_THREADS and use -lpthread.

As an example. in.telnetd will call pam_sm_authenticate() and then fork. Using
the same PAM handle, the child will then perform a pam_sm_setcred() and then
exec to the shell.

What sshd is doing is the main process (A) initializes the PAM framework, then
by simulating "pthreads" process A spawns a process B. Process B
performs the
pam_sm_authenticate(). Sometime later A spawns a process C. Process C performs
the pam_sm_setcred(). Then A spawns D to exec and become the shell.
pam_sm_setcred (according to truss) seems to also be called in D. The problem is
that any module specific data set calling pam_sm_authenticate() and
pam_sm_setcred() are in separate copies of the PAM handle (i.e. in B,C,D). It
seems that there is something that is set at each stage that the other
components rely upon. Most likely it is becuase the password is stored in B (via
pam_set_item(...,PAM_AUTHTOK,...)), and hence C or D cannot perform the keylogin
(in pam_sm_setcred) as the password is not present in the module data defined
via the PAM handle.



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