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.
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.
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?
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.
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.
closing bugs resolved before openssh-8.9