I've submitted https://github.com/SSSD/sssd/pull/7916 with the following note:

After the change in "krb5_child: do not try passwords with OTP #7462" pam_sss
broke PAM configurations like this:

auth    sufficient    pam_unix.so nullok
auth    sufficient    pam_sss.so forward_pass

What happens in this case is that the combined password+otp is entered at the
prompt generated by pam_unix, then forwarded to pam_sss. But in pam_sss any
forwarded authtok is unconditionally set to SSS_AUTHTOK_TYPE_PASSWORD. This
causes tokeninfo_matches to bail with the message "Unsupported authtok type 1"
in krb5_child.log because tokeninfo_matches no longer handles
SSS_AUTHTOK_TYPE_PASSWORD. This patch adds the logic used elsewhere in pam_sss
to determine whether a pam_authtok string should be treated as
SSS_AUTHTOK_TYPE_PASSWORD or SSS_AUTHTOK_TYPE_2FA_SINGLE. Given the duplication
it may be useful to refactor that logic into a separate function, but I tried
to keep the change minimal.

[end upstream PR]

This is a much more serious bug on debian because the broken configuration is
the default pam configuration. It does not affect the default redhat
configuration which uses:

auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
auth        [default=1 ignore=ignore success=ok]         pam_localuser.so
auth        sufficient                                   pam_unix.so nullok
auth        [default=1 ignore=ignore success=ok]         pam_usertype.so isregular
auth        sufficient                                   pam_sss.so forward_pass

and thus never prompts for a unix password from a remote user. I think the
redhat mechanism makes a lot more sense, but changing that is unlikely to
happen before freeze because it would affect multiple pam packages (and
wouldn't necessarily help upgrades anyway--leading to situations where users
can log in but cannot use sudo after an upgrade due to this bug).