Does not work when using Ed25519 key on YubiKey: Agent admitted failure to sign using the key

[Frederick888]

I'm facing a similar issue to https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1762340.html

I created an Ed25519 Authentication subkey via GnuPG and enabled it for SSH in gpg-agent. Then after copying the public SSH key into the remote machine, I was then able to SSH and sudo using the PGP key flawlessly.

However, after transferring the key to YubiKey, I can still SSH into the remote machine but when I sudo I constantly got pam_ssh_agent_auth: Agent admitted failure to sign using the key. in logs. Unlike the Debian bug report linked above, it just kept failing in my case instead of randomly succeeds.

Then still using the same YubiKey, I created an RSA 4096 Authentication subkey and transferred it into the YubiKey, then pam_ssh_agent_auth started working again.

I'm running Arch Linux on both local and remote machines. Here's some relevant info about my setup:

pam_ssh_agent_auth version: 0.10.4-2 PAM: auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys sudoers: Added Defaults env_keep += "SSH_AUTH_SOCK" ~/.ssh/rc:

if [ ! -S ~/.ssh/ssh_auth_sock ] && [ -S "$SSH_AUTH_SOCK" ]; then
    ln -sf $SSH_AUTH_SOCK ~/.ssh/ssh_auth_sock
fi

I've been using pam_ssh_agent_auth for quite some time so unless there's any additional configuration needed specially for Ed25519, I think the problem is unlikely to be caused by my setup. It's possible that this is somehow caused by YubiKey firmware or GnuPG, in which case I apologise for reporting it to the wrong place but it'd be great if you can shed some light on me to figure out whose responsibility it is.

[rfpronk]

I'm experiencing the same issue.

Using a Yubikey with a RSA4096 key for years with this module. Now I'm trying to switch to a newer Yubikey with a ed25519 key.

The stock packages (0.10.3) didn't work so I compiled the master branch of this project and included #24 but still doesn't work. Running that on Ubuntu 18.04, but also tried 20.04 and Debian Buster.

My client (MacOS Catalina) runs the latest gnupg from homebrew

➜  ~ gpg --version
gpg (GnuPG) 2.2.23
libgcrypt 1.8.7

My Yubikey 5C has firmware 5.26

I'm also not sure this project contains the error. Things like ssh itself and gpg signing works without any problems so it does point towards it. I also checked to ssh into a server and use agent forwarding to ssh into another server; that works fine. So It doesn't seem to be an error in/around agent forwarding.

Sometimes it works, mostly it doesn't. There is no pattern in how often it does. For example: (when it asks for my password I Ctrl-C out)

➜  ~ ssh server
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-45-generic x86_64)
No mail.
Last login: Wed Nov 11 18:04:19 2020 from 2001:....
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
[sudo] password for robin:
robin@server:~$ sudo echo "it works"
it works

On failures /var/log/auth.log

Nov 11 18:04:39 server sudo[15605]: pam_ssh_agent_auth: matching key found: file/command /etc/ssh/sudo_authorized_keys, line 1
Nov 11 18:04:39 server sudo[15605]: pam_ssh_agent_auth: Found matching ED25519 key: .....
Nov 11 18:04:39 server sudo[15605]: pam_ssh_agent_auth: Agent admitted failure to sign using the key.
Nov 11 18:04:39 server sudo[15605]: pam_ssh_agent_auth: Failed Authentication: `robin' as `robin' using /etc/ssh/sudo_authorized_keys
Nov 11 18:04:40 server sudo[15605]: pam_unix(sudo:auth): conversation failed

And on success

Nov 11 18:04:42 server sudo[15746]: pam_ssh_agent_auth: matching key found: file/command /etc/ssh/sudo_authorized_keys, line 1
Nov 11 18:04:42 server sudo[15746]: pam_ssh_agent_auth: Found matching ED25519 key: ....
Nov 11 18:04:46 server sudo[15746]: pam_ssh_agent_auth: Authenticated (agent): `robin' as `robin' using /etc/ssh/sudo_authorized_keys

From the client, debug logging to max , gpg agent debug log

2020-11-11 18:04:39 gpg-agent[68355] DBG: chan_9 <- OK
2020-11-11 18:04:39 gpg-agent[68355] DBG: chan_9 -> PKAUTH  OPENPGP.3
2020-11-11 18:04:39 gpg-agent[68355] DBG: chan_9 <- ERR 100663351 Invalid value <SCD>
2020-11-11 18:04:39 gpg-agent[68355] smartcard signing failed: Invalid value
2020-11-11 18:04:39 gpg-agent[68355] ssh sign request failed: Invalid value <SCD>
2020-11-11 18:04:39 gpg-agent[68355] ssh request handler for sign_request (13) ready
2020-11-11 18:04:39 gpg-agent[68355] DBG: chan_9 -> RESTART
2020-11-11 18:04:39 gpg-agent[68355] DBG: chan_9 <- OK
2020-11-11 18:04:39 gpg-agent[68355] ssh handler 0x700006334000 for fd 8 terminated

Adding debug to the pam line doesn't add useful information around this issue

Nov 11 18:16:55 server sudo[12289]: pam_ssh_agent_auth: Beginning pam_ssh_agent_auth for user robin
Nov 11 18:16:55 server sudo[12289]: pam_ssh_agent_auth: Attempting authentication: `robin' as `robin' using /etc/ssh/sudo_authorized_keys
Nov 11 18:16:55 server sudo[12289]: pam_ssh_agent_auth: Contacted ssh-agent of user robin (1000)
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: trying public key file /etc/ssh/sudo_authorized_keys
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: auth_secure_filename: checking for uid: 0
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: secure_filename: checking '/etc/ssh'
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: secure_filename: checking '/etc'
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: secure_filename: checking '/'
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: matching key found: file/command /etc/ssh/sudo_authorized_keys, line 1
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: Found matching ED25519 key: ....
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: Agent admitted failure to sign using the key.
Nov 11 18:16:56 server sudo[12289]: pam_ssh_agent_auth: Failed Authentication: `robin' as `robin' using /etc/ssh/sudo_authorized_keys

[rfpronk]

I don't know why I haven't tried this before... I created a ed25519 key file instead of using the Yubikey

ssh-keygen -o -a 256 -t ed25519

Using that key, it simply always works. So something isn't playing nice between this module, ssh agent forwarding and the Yubikey. Might be a firmware problem in the Yubikey. I will contact them about this.

[aswen]

I created that bug report. I would love to take advantage of the new Yubi with ED25519 keys so I will follow this issue :)

[jac-cbi]

I’m experiencing the same issue. My Yubikey 5C has the most recent firmware, and I’m seeing the same error message in /var/log/auth.log. (Artix Linux aarch64 on rpi4B fwiw).

I have also required touch for all actions on the yubikey. I’ve never seen the light flash yet, but I just set it up today. I’m also using ed25519 keys exclusively. SSH and SSH via agent forwarding work fine. Both require that I touch the Yubikey.

I see the Debian bug report didn’t generate any solutions yet. If ssh works with a forwarded Yubikey, I’m inclined to think that pam_ssh_agent_auth.so is the one at fault here.

[KunoiSayami]

Same here, pam log output:

Oct 18 01:04:07 sudo[25629]: pam_ssh_agent_auth: matching key found: file/command /home/114514/.ssh/authorized_keys, line 6
Oct 18 01:04:07 sudo[25629]: pam_ssh_agent_auth: Found matching ED25519 key: f9:00:00:00:00:00:00:00:00:00:00:00:00:00:03:65
Oct 18 01:04:07 sudo[25629]: pam_ssh_agent_auth: Agent admitted failure to sign using the key.

[FlorianFranzen]

I ran into the same issue on NixOS. A second RSA key on an older yubikey works flawlessly in the same setup.

After reading gnupg#5041 I am worried this could be on the yubikey side. Has anyone tried reducing the size of the data passed to the yubikey to be signed? The standard does not limit the size of the data passed, yet most digital signatures probably use Ed25519ph.

[FlorianFranzen]

I applied the following patch in a lazy attempt to reduces the size of the data being signed:

--- a/iterate_ssh_agent_keys.c
+++ b/iterate_ssh_agent_keys.c
@@ -188,7 +188,7 @@ pamsshagentauth_find_authorized_keys(const char * user, const char * ruser, cons
     uid_t uid = getpwnam(ruser)->pw_uid;

     OpenSSL_add_all_digests();
-    pamsshagentauth_session_id2_gen(&session_id2, user, ruser, servicename);
+    //pamsshagentauth_session_id2_gen(&session_id2, user, ruser, servicename);

     if ((ac = ssh_get_authentication_connection(uid))) {
         pamsshagentauth_verbose("Contacted ssh-agent of user %s (%u)", ruser, uid);

Now GnuPG consistently sends around 145 bytes to the yubikey to sign instead of previously often up to 800 bytes. As a result everything just works again, as it does with my 4k RSA keys.

Part of the session id the patch removes is a randomly sized cookie (16-255 bytes), which explains why the yubikey would sometimes still work. If you are lucky with a small cookie size and executing a short sudo command from a short path on a host with a short hostname the yubikey can handle the signature.

A patch in the spirit of the codebase would probably just limit the size of the cookie (currently up to 256 bytes) and maybe remove some of the fields.

Personally I would get rid of everything and just send a fixed size of random bytes. Sending all this info to the agent who just blindly signs it will only ever serve as a information leak at best.

Anyhow, this puts the problem on the side of the Yubikey and I am in touch with Yubico about it.

EDIT: I wrote a more intelligent version that just send 1024 random bits as session id that I am currently using successfully on multiple production systems. It is available here.

It essentially generates the session id like this:

    for (i = 0; i < 32; i++) {    
        pamsshagentauth_buffer_put_int(session_id2, pamsshagentauth_arc4random());
    }

(Yes, this is how the current codebase does it for cookies too. And I know about arc4random_buf(...), but it might not be available on BSD.)

[KunoiSayami]

Thx @FlorianFranzen's share, it works for me now.

[git-noise]

@FlorianFranzen Oh many thanks for this one, it bothered me for a long time. Would you have any news on the Yubico discussion by any chance?

Best,

[bootc]

This is actually fixed with GnuPG 2.3.4 and 2.2.33 - look at the changelog entry marked T5682. You'll see the latter even links back here, though no mention of it was made here.

I can confirm that GnuPG 2.3.4 on my Mac via Homebrew does indeed fix this issue for me.