openssh bugs - Apr 2021 - [Bug 3303] New: Request Match block accommodation for 2FA sshd_config

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

            Bug ID: 3303
           Summary: Request Match block accommodation for 2FA sshd_config
           Product: Portable OpenSSH
           Version: 8.6p1
          Hardware: Other
                OS: Windows 10
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: alwanza at yahoo.com

Explanation of how the bug works:
Users can ssh into the SSH SERVER using the following methods:
1.      password and 2FA    (this is as designed)
2.      ssh-key with passphrase and 2FA   (this is as designed)
3.      password and enter and  password (entering the same password
twice)  (this is a bug)
4.      ssh-key with passphrase and enter and password  (this is a bug)

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

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Meryll <alwanza at 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.

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

Meryll <alwanza at yahoo.com> changed:

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at dtucker.net> changed:

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

--- Comment #1 from Darren Tucker <dtucker at 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.

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

--- Comment #2 from Meryll <alwanza at 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.

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.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Darren Tucker <dtucker at dtucker.net> ---
We've just made ChallengeResponseAuthentication a (deprecated) alias of
KbdInteractiveAuthentication, so both are now equivalent and usable
under Match.

The rest of this seems to be related to the PAM configuration, which is
outside of the scope of sshd.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
closing bugs resolved before openssh-8.9

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