Multifactor authentication troubles
vincent.brillault at cern.ch
Wed Jul 27 16:49:29 AEST 2016
Dear Darren, James,
> 1) Use the per-auth-type PAM configs as per
> 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
> 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
For more details on how to use that patch:
(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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the openssh-unix-dev