[Bug 3303] Request Match block accommodation for 2FA sshd_config

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Wed Apr 28 10:04:24 AEST 2021


https://bugzilla.mindrot.org/show_bug.cgi?id=3303

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
Oh, I missed the main point in your original report.  I am assuming
you're using PAM for your 2FA as it is by far the most common way to
implement this kind of thing.

First, some terminology: in SSHv2, "password" authentication is simple
password passed via the encrypted session.  When PAM is enabled, that
password is blindly passed to PAM whenever it asks anything, so this
only works for very simple PAM configurations.  "keyboard-interactive"
is more capable, and passes whatever PAM asks and the user response
more or less verbatim.  In the case where PAM is configured to use
plain text passwords, this interaction is something like a "Password: "
prompt and corresponding response from the user, and while this
contains the string "password", from SSH's perspective it is NOT
password authentication.  If you have non-trivial PAM configuration you
almost certainly want to set PasswordAuthentication=no and rely
exclusively on keyboard-interactive.

(In reply to Meryll from comment #0)
[...]
> 3.	password and enter and  password (entering the same password
> twice)  (this is a bug)

What's likely happening here is that of "password, publickey, and
keyboard-interactive", you are using both password and
keyboard-interactive, and keyboard-interactive is interacting with PAM,
which is allowing a plain text password.

> Per ssh error message:
> Directive 'ChallengeResponseAuthentication' is not allowed within a
> Match Block

This is true but is unrelated to what you're trying to do.

> In order to permit users to authenticate with EITHER a long password
> OR an ssh-key that is protected with a passphrase, 

> we introduced “Match” blocks in our sshd_config file.
> The “Match” blocks permit SOME users to use a password AND other
> users to use an ssh-key protected with a passphrase.
> 
> The allowable authentication methods in a Match block include: 
> password, publickey, and keyboard-interactive
> 
> The problem is that “keyboard-interactive” is NOT restricted to
> meaning “2FA” and there is no way to restrict it to mean “2FA”.
> “keyboard-interactive”  CAN also mean “password”.  So if the user
> just enters an empty Verification Code, the user is presented with a
> password prompt.

This is a function of whatever is backing the keyboard-interactive
auth, most likely PAM.  If you want to allow a subset of users to be
required to 2FA and some not, that's something you need to configure in
the PAM stack (and disable PasswordAuthentication in sshd_config).

sshd sets SSH_AUTH_INFO_0 in the PAM environment (see bz#2408) and that
includes the methods that have succeeded so far.  I think you can
implement the semantics you want using that in your PAM stack, although
exactly how would depend on the PAM implementation (eg by using
LinuxPAM's advanced control syntax to skip pam_unix.so if
SSH_AUTH_INFO_0 contains "keyboard-interactive" before requiring your
2FA module).

The other possibility (and this is not supported by stock OpenSSH) is
that some vendors have modified sshd such that you can use different
PAM stacks for different SSH auth methods.  In that case you'd
configure the password stack with pam_unix.so, the keyboard-interactive
stack with your 2FA and use both in your sshd_config.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list