When I add two keys to .ssh/authorized_keys on a remote system, it appears that only one of them will be attempted (in only a couple of trials, it was the first key I'd created both times, even after I swapped the order of the two keys in .ssh/authorized_keys). This results in an error if the "right" key isn't already inserted. I would expect the correct behavior to be to attempt only remote-host-authorized keys that are inserted in the local host, and if none are inserted, to prompt the user to insert one.
If you post debug traces from the client and the server it might be possible to figure out what is going on here
Hmmm... I still have the issue of not being prompted to insert a key when no acceptable key is already inserted, but either of the keys I've authorized can be inserted and I get logged in without error. I'm pretty sure Tumbleweed has had an update to this stuff (libfido2 and maybe openssh) since I originally reported the issue, so it looks maybe like this has been resolved. If it's useful, though, I'll attach logs for two cases where an authorized key is already inserted and one where no key is inserted. FYI, I tested this on my laptop by starting sshd on my laptop and "ssh -vvv localhost". The authorized_keys file contained only the two Yubikeys I've been testing with.
Created attachment 3429 [details] 5C Nano already inserted
Created attachment 3430 [details] 5 NFC already inserted
Created attachment 3431 [details] No key inserted
it sounds like your problems were related to your OS distribution and not OpenSSH per se. Reopen if this is not the case.
closing resolved bugs as of 8.6p1 release