Mailing List Archive

[Bug 3303] Request Match block accommodation for 2FA sshd_config
https://bugzilla.mindrot.org/show_bug.cgi?id=3303

Meryll <alwanza@yahoo.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
OS|Windows 10 |Linux
Priority|P5 |P3

--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3303] Request Match block accommodation for 2FA sshd_config [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=3303

Meryll <alwanza@yahoo.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |alwanza@yahoo.com

--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3303] Request Match block accommodation for 2FA sshd_config [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=3303

Darren Tucker <dtucker@dtucker.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |dtucker@dtucker.net
Blocks| |3302

--- Comment #1 from Darren Tucker <dtucker@dtucker.net> ---
ChallengeResponseAuthentication is actually the SSH protocol 1 option.
KbdInteractiveAuthentication is the protocol 2 option and you can use
it in a Match block right now.

The reason ChallengeResponseAuthentication was excluded from Match is
that it behaved in an unusual way for a config option (it'd enable
KbdInteractiveAuthentication if it was not set, but quite late in the
process, in a way not conducive to working with Match).

These days Protocol 1 is gone and the two are effectively equivalent,
so we should remove the discrepancy.


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3302
[Bug 3302] Tracking bug for openssh-8.7
--
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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3303] Request Match block accommodation for 2FA sshd_config [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=3303

--- Comment #2 from Meryll <alwanza@yahoo.com> ---
Darren - thank you for your response. It was worth a try... but didn't
seem to solve my issue.

KbdInteractiveAuthentication was an accepted directive both within the
sshd_config file and the Match block.

When I substituted KbdInteractiveAuthentication for
ChallengeResponseAuthentication, I was no longer prompted for my
"Verification Code" at login. After entering the passphrase associated
with my public key I was prompted for a "password" and nothing I
entered (password, passphrase, nor authentication code) was accepted,
so I was effectively locked out.

When I reenabled ChallengeResponseAuthentication with
KbdInteractiveAuthentication, there was no change from the original
behavior I described.

My openssh version is 8.0 (on CentOS 8.3.2011). I am using Google
Authenticator as my 2FA.

Did I miss a step?

--
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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 3303] Request Match block accommodation for 2FA sshd_config [ In reply to ]
https://bugzilla.mindrot.org/show_bug.cgi?id=3303

--- Comment #3 from Darren Tucker <dtucker@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs