FS#74143 - [openssh] Can't authenticate with gpg-agent usb token since 8.9p1-1

Attached to Project: Arch Linux
Opened by James Hogan (jhogan) - Wednesday, 16 March 2022, 16:10 GMT
Last edited by David Runge (dvzrv) - Saturday, 19 November 2022, 22:35 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Since updating openssh to 8.9p1-1, I can't authenticate via gpg-agent using a USB hardware token.

gpg-agent shows the pinentry dialog, but then ssh says:
sign_and_send_pubkey: signing failed for ED25519 "cardno:***" from agent: agent refused operation

Downgrading to openssh-8.8p1-1 fixes it.

Updating gnupg to 2.2.33 or 2.2.34 (by manually editing the gnupg PKGBUILD since the archlinux version is out of date) and doing "gpgconf --kill gpg-agent", "gpgconf --launch gpg-agent" did not fix it.

I have this in my environment:
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh

and enable-ssh-support in ~/.gnupg/gpg-agent.conf
and it has worked fine until now.
This task depends upon

Closed by  David Runge (dvzrv)
Saturday, 19 November 2022, 22:35 GMT
Reason for closing:  Upstream
Additional comments about closing:  Upstream issues with firmware.
Comment by Bryan Childs (godeater) - Monday, 21 March 2022, 22:32 GMT
I think this *may* be a more general error when the 8.9p1 client is trying to communicate with an ssh-agent which isn't the one shipped with the 8.9p1 package.
I've run into a similar issue this morning when trying to ssh from my ArchLinux WSL instance (I know, I know - not supported - but I thought this was worth mentioning to help track down the issue). I have the ssh-agent in windows holding my ssh keys, which is running the default ssh version shipped with windows - 8.1p1. The WSL instance communicates with that, and ssh-add lists the keys loaded into it perfectly fine. But ssh itself logs

debug1: get_agent_identities: ssh_fetch_identitylist: communication with agent failed

When you try to use it to connect to a remote host. This previously worked flawlessly until I got the upgrade to 8.9p1.

If I run the local ssh-agent in the WSL instance itself, and load a key in there - then ssh works fine loading the key from the agent.
Comment by Bryan Childs (godeater) - Tuesday, 22 March 2022, 00:05 GMT
https://www.openssh.com/agent-restrict.html <- I think this is probably related.
Comment by Bryan Childs (godeater) - Friday, 01 April 2022, 06:21 GMT
I managed to upgrade the OpenSSH binaries on my windows box to 8.9p1 now, and even though the windows build doesn't support the key restrictions, it's agent does now know how to talk to the ssh binary in my Arch WSL instance - so the problem has disappeared for me. I think this does point to the fact that the gpg-agent used by OP isn't speaking the right language to their ssh client any more.

Incidentally, I'm now using ed25519-sk keys with USB hardware token (a Yubikey in my case) natively with ssh - so there's no need to use gpg for that feature anymore.
Comment by Iru Dog (mytbk) - Thursday, 14 April 2022, 05:27 GMT
I can use OpenSSH 8.9p1 with gpg-agent+Gnuk, but after upgrading to 9.0p1 it doesn't work. I don't know if it's the same problem.
Comment by Iru Dog (mytbk) - Thursday, 14 April 2022, 07:00 GMT
I can use OpenSSH 8.9p1 with gpg-agent+Gnuk, but after upgrading to 9.0p1 it doesn't work. I don't know if it's the same problem.
Comment by Iru Dog (mytbk) - Sunday, 17 April 2022, 07:07 GMT
My problem is solved by disabling the new KEX algorithm in ~/.ssh/config:

KexAlgorithms -sntrup761x25519-sha512@openssh.com

So my problem in 9.0p1 is caused by sntrup761x25519 as default in OpenSSH.
Comment by Raffael Willems (bigfreak) - Monday, 18 April 2022, 19:59 GMT
thx @Iru Dog added KexAlgorithms -sntrup761x25519-sha512@openssh.com to my /etc/ssh/ssh_config and yubikey works again :-D
Comment by David Runge (dvzrv) - Friday, 06 May 2022, 14:36 GMT
I am experiencing the same with a Nitrokey Start. I am unable to use it with openssh > 8.8p1 (client-side) to authenticate against a remote machine.
Unfortunately removing the new default by using `KexAlgorithms -sntrup761x25519-sha512@openssh.com` does not work (see upstream issue: https://github.com/Nitrokey/nitrokey-start-firmware/issues/67).
Comment by James Hogan (jhogan) - Friday, 06 May 2022, 15:59 GMT
Thanks for the link, hadn't seen that report.

There's also a report against gnupg upstream here: https://dev.gnupg.org/T5931

with the comment:
> Nitrokey Start uses Gnuk as its firmware. You need to upgrade its firmware to version 1.2.16 or newer.
> Please note that when upgrading the firmware, your keys will be removed.

I haven't got around to trying it yet.
Comment by David Runge (dvzrv) - Saturday, 19 November 2022, 22:35 GMT
For nitrokey start this is fixed with firmware >= RTM.13-RC2 [1].

As this issue is not directly related to openssh but rather the firmwares of the respective authentication token, I'll close this ticket.
If there are further issues, please reach out to the manufacturer of your hardware for a firmware fix.

[1] https://github.com/Nitrokey/nitrokey-start-firmware/releases/tag/RTM.13-RC2

Loading...