stopped recognizing security-key based keys after upgrade

[jnperry]

i upgraded to the latest version today, and it no longer recognizes my ssh keys.

error:
Jun 12 01:07:21 choco sudo[4581]: pam_ssh_agent(sudo:auth): Authenticating user 'xyz' using ssh-agent at 'xyz''
Jun 12 01:07:21 choco sudo[4581]: pam_ssh_agent(sudo:auth): authorized keys from '/etc/security/authorized_keys-xyz'
Jun 12 01:07:22 choco sudo[4581]: pam_ssh_agent(sudo:auth): signature error: Key type is not supported: SkEd25519
Jun 12 01:07:22 choco sudo[4581]: pam_ssh_agent(sudo:auth):
Jun 12 01:07:22 choco sudo[4581]: pam_ssh_agent(sudo:auth): Caused by:
Jun 12 01:07:22 choco sudo[4581]: pam_ssh_agent(sudo:auth): Key type is not supported: SkEd25519
Jun 12 01:07:25 choco sudo[4581]: pam_unix(sudo:auth): conversation failed
Jun 12 01:07:25 choco sudo[4581]: pam_unix(sudo:auth): auth could not identify password for [xyz]

keytype is sk-ssh-ed25519@openssh.com

confusing as i don't see any commits offhand that could have caused it. neither build had any feature flags specifically set by me.

[jnperry]

this was caused because the AUR (archlinux) package was compiling with --all-features
when i removed that, it resumed working.

[nresare]

Thank you for the report, and good find! The native crypto feature is not really a feature in the traditional sense, but rather an alternative less tested code path.

That said, I believe that supporting the Sk key is a simple matter of unwrapping the public key. Unfortunately, I don't have any hardware readily available to test this. Would you mind compiling the have_nativecrypto_handle_sk_keys branch with the --all-features flag set and see if it works? If it works we can land this and fix the regression :)

[jnperry]

sure! the new branch has a different error:

Jun 14 11:38:56 udon-kino sudo[20190]: pam_ssh_agent(sudo-i:auth): signature error: unsupported signature type
Jun 14 11:38:56 udon-kino sudo[20190]: pam_ssh_agent(sudo-i:auth):
Jun 14 11:38:56 udon-kino sudo[20190]: pam_ssh_agent(sudo-i:auth): Caused by:
Jun 14 11:38:56 udon-kino sudo[20190]: pam_ssh_agent(sudo-i:auth): unsupported signature type

[nresare]

Ah, so the both the key and the signature are a little different. That complicates things a bit. What model hardware token is it that you have? It would be useful to be able to reproduce this locally

[jnperry]

Bus 003 Device 006: ID 1050:0406 Yubico.com Yubikey 4/5 U2F+CCID

it's not super important to fix (at least for me) since i can just turn off the all-features enable in the package

[deajan]

Willing to step in, I use some Yubikey 5 hardware, compiled your branch and got the following:

PAM unable to dlopen(/usr/lib64/security/pam_ssh_agent.so): /usr/lib64/security/pam_ssh_agent.so: undefined symbol: EVP_DigestVerify
PAM adding faulty module: /usr/lib64/security/pam_ssh_agent.so

This was done on my legacy builder machine (RHEL7) with openssl-libs-1.0.2k-26.el7_9.x86_64
I decided that since this openssl lib is pretty old (and retired), I'd try with a newer builder (RHEL9), which uses openssl-3.5.5-4.el9_8.x86_64.
On this system your branch works just fine. Actually, just for the sake of testing, I also build and ran the main branch which also works flawlessly.

I use an ecdsa-sha2-nistp384 on my yubikey which might be the problem here since we're not talking about the same crypto.
AFAIK yubikeys didn't support Ed25519 PIV keys until firmware 5.7.x or so.

@jnperry Do you use PIV or FIDO on your keys ? And what's your yubikey firmware please ?

[deajan]

Self answering myself, didn't see the "sk" prefix, so it's obviously FIDO.
I tend to use PIV, but can test by setting up a FIDO key if needed.

[jnperry]

hi! sorry for the delay.

Device type: YubiKey 5C Nano
Serial number: 356xxxxx
Firmware version: 5.7.4
Form factor: Nano (USB-C)
Enabled USB interfaces: FIDO, CCID

the key is ed25519 with sha256.
i'm not using fido2 (which would be a resident credential); this is using u2f