FS#74423 - [openssh] [gnupg] openssh 9.0 no longer works with YubiKey via gpg-agent

Attached to Project: Arch Linux
Opened by Jan Alexander Steffens (heftig) - Saturday, 09 April 2022, 17:56 GMT
Last edited by Giancarlo Razzolini (grazzolini) - Wednesday, 13 April 2022, 16:53 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

I have SSH_AUTH_SOCK set to $XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh in order to connect to gpg-agent,
which provides access to the ED25519 authentication key on my YubiKey 5C.

With openssh 8.9p1-1, ssh works fine.

With openssh 9.0p1-1, ssh still triggers gpg-agent to unlock the key if it's locked, but then fails to use it:

sign_and_send_pubkey: signing failed for ED25519 "cardno:***" from agent: agent refused operation
sign_and_send_pubkey: signing failed for ED25519 "(none)" from agent: agent refused operation
heftig@build.archlinux.org: Permission denied (publickey).

At the same time, gpg-agent produces some logs:

gpg-agent[6363]: detected card with S/N ***
gpg-agent[6365]: scdaemon[6365]: app_auth failed: Invalid value
gpg-agent[6363]: smartcard signing failed: Invalid value
gpg-agent[6363]: ssh sign request failed: Invalid value <SCD>
gpg-agent[6363]: detected card with S/N ***
gpg-agent[6365]: scdaemon[6365]: app_auth failed: Invalid value
gpg-agent[6363]: smartcard signing failed: Invalid value
gpg-agent[6363]: ssh sign request failed: Invalid value <SCD>

Additional info:
* openssh 9.0p1-1, gnupg 2.2.32-2, pcsclite 1.9.5-1
This task depends upon

Closed by  Giancarlo Razzolini (grazzolini)
Wednesday, 13 April 2022, 16:53 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Upstream intentionally enabled this.
Comment by freswa (frederik) - Saturday, 09 April 2022, 20:07 GMT
Seems related to the new Default of KexAlgorithms, also mentioned here: https://lwn.net/Articles/890803/
Comment by Jan Alexander Steffens (heftig) - Saturday, 09 April 2022, 20:38 GMT
KexAlgorithms -sntrup761x25519-sha512@openssh.com
does indeed solve this problem, so this is no longer a blocker for me.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 11 April 2022, 12:45 GMT
I'm not sure we should disable this. Upstream clearly enabled this to prevent "collect now, decrypt later" situations with post-quantum computing. Should we perhaps document this workaround on the wiki?

Loading...