I'm writing a PAM module to do authentication through Signal (as in Open Whisper Systems) [1]. I would like to be able to offer (Public key AND Signal) or (Password AND Signal) for authentication. This suggests setting AuthenticationMethods to publickey,keyboard-interactive:pam password,keyboard-interactive:pam However, when PAM is enabled "password" means "show password prompt, then do PAM", which is a problem because my PAM does Signal auth, not password auth, and the above results in all login attempts failing. Clearly sshd knows how to do password auth without PAM because it works even when PAM is disabled, so I wonder if there is some way to request that "password" does not use PAM even when PAM is enabled? Ideally one could specify something like password:nopam password:builtin Or another solution would be to allow multiple different PAM modules to be called instead of requiring it all to be lumped into /etc/pam.d/sshd. Then one could specify something like PAMFiles /etc/pam.d/sshd* AuthenticationMethods keyboard-interactive:pam:sshd-pass,keyboard-interactive:pam:sshd-signal Does this kind of functionality already exist, and if not would it be feasible to implement? Thank you for your help, James Murphy [1] https://github.com/kb100/signal-authenticator
On Sat, Jul 23, 2016 at 5:50 AM, James Murphy <james.murphy.debian at gmail.com> wrote:> I'm writing a PAM module to do authentication through Signal (as in Open > Whisper Systems) [1]. I would like to be able to offer > (Public key AND Signal) or (Password AND Signal) > > for authentication. This suggests setting AuthenticationMethods to > publickey,keyboard-interactive:pam password,keyboard-interactive:pam > > However, when PAM is enabled "password" means "show password prompt, > then do PAM", which is a problem because my PAM does Signal auth, not > password auth,The PAM conversation is whatever you configure the stack to be, not just one of password or Signal. For example you could have this in your PAM ssh config: auth required pam_unix.so auth requred pam_signal.so and as long as you're using SSH Protocol 2, it should allow multiple conversations in a single call to pam_authenticate. That should get you the "password then Signal" authentication via only keyboard-interactive. [...]> Or another solution would be to allow multiple different PAM modules to > be called instead of requiring it all to be lumped into /etc/pam.d/sshd.There's an open enhancement request for this: https://bugzilla.mindrot.org/show_bug.cgi?id=2246> Then one could specify something like > > PAMFiles /etc/pam.d/sshd* > AuthenticationMethods > keyboard-interactive:pam:sshd-pass,keyboard-interactive:pam:sshd-signalYou can get this behaviour by putting both auth modules in the ssh stack config as described above and that should work with the current production code. Getting (Public key AND Signal) or (Password AND Signal) to work is trickier. I can imagine 2 ways to do it, both of which require changes not in the current production code. 1) Use the per-auth-type PAM configs as per https://bugzilla.mindrot.org/show_bug.cgi?id=2246. 2) Configure the ssh-passwd stack to have just pam_unix.so and the ssh-kbdint stack to have just pam_signal.so. 3) Put "AuthenticationMethods password,keyboard-interactive publickey,keyboard-interactive" into sshd_config. sshd should offer you either of publickey or password first then proceed to keyboard-interactive. OR (and this one is fuzzier) a) Use "expose authentication information to PAM" as per https://bugzilla.mindrot.org/show_bug.cgi?id=2408 b) Put "AuthenticationMethods "publickey,keyboard-interactive keyboard-interactive" in sshd_config c) Put both pam_unix.so and pam_signal.so in the PAM config and have it somehow check for the indication that pubkey has been successful and if found, skip pam_unix somehow. I don't know of a way to do that offhand though. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On 07/23/2016 05:53 PM, Darren Tucker wrote:> 1) Use the per-auth-type PAM configs as per > https://bugzilla.mindrot.org/show_bug.cgi?id=2246. > 2) Configure the ssh-passwd stack to have just pam_unix.so and the > ssh-kbdint stack to have just pam_signal.so. > 3) Put "AuthenticationMethods password,keyboard-interactive > publickey,keyboard-interactive" into sshd_config.This seems to be exactly what I'm looking for. I see that a patch was written on 2015-04-16 that implements this functionality, though there has been no action taken or feedback given on the patch since then. Has this slipped through the cracks, or were there more issues that needed to be resolved before merging? James Murphy
Dear Darren, James,> 1) Use the per-auth-type PAM configs as per > https://bugzilla.mindrot.org/show_bug.cgi?id=2246. > 2) Configure the ssh-passwd stack to have just pam_unix.so and the > ssh-kbdint stack to have just pam_signal.so. > 3) Put "AuthenticationMethods password,keyboard-interactive > publickey,keyboard-interactive" into sshd_config. > > sshd should offer you either of publickey or password first then > proceed to keyboard-interactive.One downside of such an approach is that "password", as far as I understand, has less feature than "keyboard-interactive:pam". For example, it does not support "password change": if you are want to be able to force your users to change their password on the next successful logins, that won't work with "password".> OR (and this one is fuzzier)What do you mean by "fuzzier"? It looks simpler to me ;) Full disclosure: I'm one of the author of that patch> a) Use "expose authentication information to PAM" as per > https://bugzilla.mindrot.org/show_bug.cgi?id=2408 > b) Put "AuthenticationMethods "publickey,keyboard-interactive > keyboard-interactive" in sshd_config > c) Put both pam_unix.so and pam_signal.so in the PAM config and have > it somehow check for the indication that pubkey has been successful > and if found, skip pam_unix somehow. I don't know of a way to do that > offhand though.You need a small pam module for that, for example https://github.com/CERN-CERT/pam_2fa/blob/master/pam_ssh_user_auth.c For more details on how to use that patch: https://cern-cert.github.io/pam_2fa/#using-a-smart-pam-configuration (The rest of that page explains why we think we need that patch) A small additional benefit of that patch is that pam will have more information on what made the first factor succeed and can be then used to learn "who connected as root" (shared account) and match this information to the corresponding 2nd factor (valid for that particular account and not simply any user allowed to login with that account). Cheers, Vincent -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160727/851fe619/attachment.bin>