                Frequently asked questions
                ==========================


-----------------------------------------------------------------------

Q.  What does the following error mean: pam_csync: error trying to

A.  This often means that the pam_csync module was not executed as an
    auth type module. This error is usually due to a misconfigured auth
    PAM stack (/etc/pam.d/<service>). For example, if you use an auth
    PAM module configured with the control flag of sufficient, then
    pam_csync needs to be executed before it.

-----------------------------------------------------------------------

Q.  Why does pam_csync not work right with OpenSSH?

A.  As of version 3.3, sshd has a feature called privilege separation
    that is incompatible with PAM modules needing root privileges. In
    addition, OpenSSH does not use PAM by default. OpenSSH before 4.9
    does not properly deal with PAM. See bugs.txt.

    [...]

    Finally, Darren Tucker has explained:

        OK, here is what is happening: sshd forks when doing
        challenge-response authentication, and the pam_authenticate
        call happens in the child (the authentication "thread",
        although it is normally a process).

        This, BTW, is because pam_authenticate blocks while waiting for
        responses from the conversation function. In sshd this blocking
        means that the dispatch loop (which is needed to communicate
        with the user) is not running until pam_authenticate completes,
        but it cannot complete until because the dispatch loop is not
        running. Another process is used to prevent this deadlock.

        It would appear that pam_csync relies on either module-private
        data set during the pam_authenticate or the PAM_AUTHTOK item,
        both of which are lost when the the authentication "thread"
        exits. pam_csync goes looking for them during session
        initialization in order to authenticate to the SMB server,
        cannot get them and fails.

        Since you have OpenSSH 3.9p1, you can set
        "ChallengeResponseAuthentication no" and
        "PasswordAuthentication yes" in sshd_config and it ought to
        work (with or without privsep).

        If you absolutely *must* have challenge-response authentication
        then you can build OpenSSH with the pthread hack, but this it
        not recommended.

        If you have trouble with it not dismounting then you will need
        to apply the patch in this bug (this one only works with
        privsep=no, and I cannot see a good way to fix this for the
        general case): http://bugzilla.mindrot.org/show_bug.cgi?id=926
