[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_mount error with sshd

Dawson, Alan wrote:
Using pam_mount version 0.9.21 and OpenSSH 3.9p1 on SUSE LINUX 9.2

Privilige Separation is disabled

I have pam_mount mounting home folders from a remote Windows server happily
on the Linux box, with local logins ( ie using pam.d/login )

Users can logon happily to using ssh ( ie using pam.d/ssh ) but
pam_mount gives errors when trying to mount the remote directory for
an ssh session

"Jan 21 15:38:07 SUSE92 PAM-warn[30346]: function=[pam_sm_acct_mgmt]
service=[sshd] terminal=[ssh] user=[dawsona] ruser=[<unknown>]
Jan 21 15:38:07 SUSE92 sshd[30345]: Accepted keyboard-interactive/pam for
dawsona from ::ffff: port 1443 ssh2
Jan 21 15:38:07 SUSE92 sshd[30347]: pam_mount: error trying to retrieve
authtok from auth code
Jan 21 15:38:07 SUSE92 sshd[30347]: pam_mount: error trying to read password
Jan 21 15:38:07 SUSE92 sshd[30347]: fatal: PAM: pam_open_session():
Permission denied"

OK, here's what's happening: sshd forks when doing challenge-response authentication, and the pam_authenticate call happens in the child (the authentication "thread", although it's 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) isn't running until pam_authenticate completes, but it can't complete until because the dispatch loop isn't running. Another process is used to prevent this deadlock.

It would appear that pam_mount 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_mount goes looking for them during session initialization in order to authenticate to the SMB server, can't get them and fails.

For the gory details of the sshd side see

Has anybody got a working pam sshd config with pam_mount I can crib or a
workaround ? thanks

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'll need to apply the patch in this bug (this one only works with privsep=no, and I can't see a good way to fix this for the general case):

Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]