openssh unix dev - Jul 2016 - Multifactor authentication troubles

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-signal
You 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>