Page MenuHome GnuPG

SSH agent failing "agent refused operation"
Open, Needs TriagePublic

Description

Hi,

Recently I've been having issues with the SSH agent of Gpg4win. The behavior is very weird and even after diving into logs (enabled debug) and trying various scenario's and versions I have no clue why it's not working anymore.
It used to work fine and I have no clue what changed creating all sorts of issues since a few days ago.

Setup:

  • YubiKey 5 NFC
  • gpg-agent.conf with enable-ssh-support, enable-putty-support and enable-win32-openssh-support
  • Windows 11 24H2
  • OpenSSH for Windows 9.8p1
  • Gpg4win (have tried versions 4.2.0, 4.4.0 and 5.0.0-beta51, all having the same issues)
  • WSL 2 running Ubuntu 24.10

1. ssh.exe/ssh-add.exe failing every other request

When from PowerShell I run ssh-add -L it alternates between giving the list of identities including my YubiKey, and giving the error error fetching identities: agent refused operation.
It consistently alternates between a successful answer and the error. It doesn't seem to matter if I run the command 100 times in 10 seconds, or if I wait 30 seconds or even longer between running the commands.
It's always success - failure - success - failure - success - failure - etc.
With debug-level = guru and debug-all enabled for the failures nothing is logged, indicating that for the failed attempts it's not even reaching the agent.
This also happens when I unplug my YubiKey, then it just cycles between The agent has no identities. and the same error.

The same happens when I try to connect to a server. If I run ssh myserver.com the first time it connects successfully, then close the connection and try again it fails, using -vvv I can see:

debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused operation
debug1: get_agent_identities: ssh_fetch_identitylist: agent refused operation

I can repeat this indefinitely and again get success - failure - success - failure - etc.
This makes it impossible to connect to any server through a hop, as one of the two will always fail.

This behavior is also reproduced in my WSL Ubuntu when I use npiperelay.exe to relay agent requests to the named pipe //./pipe/openssh-ssh-agent.

2. PuTTY / Pageant crashes gpg-agent

When I use PuTTY to try the Pageant integration but without my YubiKey connected the gpg-agent appears to crash. The last thing I see in the logs is:

2025-01-31 17:48:28 gpg-agent[1476] error getting list of cards: No such device
2025-01-31 17:48:28 gpg-agent[1476] ssh request handler for request_identities (11) ready
2025-01-31 17:48:28 gpg-agent[1476] DBG: chan_0x00000000000002d0 -> RESTART
2025-01-31 17:48:28 gpg-agent[1476] DBG: chan_0x00000000000002d0 <- OK

If I have my YubiKey connected the behavior is a bit different. Here I see in the logs that after the Pageant request comes in it starts scdaemon and reads the keys from my YubiKey.

2025-01-31 17:58:48 gpg-agent[19760] ssh request handler for request_identities (11) ready
2025-01-31 17:58:48 gpg-agent[19760] DBG: chan_0x00000000000002c4 -> RESTART
2025-01-31 17:58:48 gpg-agent[19760] DBG: chan_0x00000000000002c4 <- OK
2025-01-31 17:58:53 gpg-agent[5412] listening on socket 'C:\\Users\\***\\AppData\\Local\\gnupg\\S.gpg-agent'
2025-01-31 17:58:53 gpg-agent[5412] listening on socket 'C:\\Users\\***\\AppData\\Local\\gnupg\\S.gpg-agent.extra'
2025-01-31 17:58:53 gpg-agent[5412] listening on socket 'C:\\Users\\***\\AppData\\Local\\gnupg\\S.gpg-agent.browser'
2025-01-31 17:58:53 gpg-agent[5412] listening on socket 'C:\\Users\\***\\AppData\\Local\\gnupg\\S.gpg-agent.ssh'
2025-01-31 17:58:53 gpg-agent[5412] gpg-agent (GnuPG) 2.5.3 started
2025-01-31 17:58:53 gpg-agent[5412] putty message loop thread started
2025-01-31 17:58:53 gpg-agent[5412] Win32-OpenSSH thread started

Based on the pid it seems gpg-agent crashes again, but in this scenario manages to restart itself. After that I see 15 times the message Assuan accept problem: Input/output error.

Sometimes I also see the message:

2025-01-31 18:03:55 gpg-agent[22948] error binding socket to 'C:\\Users\\***\\AppData\\Local\\gnupg\\S.gpg-agent': Unknown error

Maybe that's because the socket from the previous process hasn't been freed yet when it restarts?

3. Inside WSL ssh-add -L works via the Assuan file socket, but not ssh

If inside WSL I use npiperelay.exe to forward to the agent using the named pipe //./pipe/openssh-ssh-agent I get the same behavior as described in point 1.
However if I instead point it to the Assuan file socket S.gpg-agent.ssh then ssh-add -L works almost all the time, but trying to do any connecting using ssh always fails with:

debug2: get_agent_identities: ssh_agent_bind_hostkey: agent refused operation
debug1: get_agent_identities: ssh_fetch_identitylist: communication with agent failed

Here though I am not sure if it's related to gpg-agent or it has to do with the relaying of npiperelay.exe so I'm not really focused on this.
Just including it to for completeness sake.

4. gpg works fine

When using gpg, for example gpg --card-status or when signing Git commits it always works. The issues seem specific to the SSH integration.

5. gpg-agent works fine in WSL with usbipd

If I stop the gpg-agent in Windows and use usbipd to attach my YubiKey directly to WSL, the agent that then runs inside Ubuntu (no Gpg4win here, Ubuntu 24.10 comes with GnuPG 2.4.4) works fine without issues.
I can see the YubiKey, I can sign Git commits and I can use ssh-add -L and connect to any server using ssh without problems consistently.
This however comes with the problem that while the YubiKey is attached to WSL, it's not useable in Windows. That makes using it very cumbersome.

Next steps?

Right now I'm stuck and have no clue on what's going on or how to further diagnose things.
If there is anything I can try, or provide more logs or other details, happy to do so.

Details

Version
4.4.0

Event Timeline

I never tested the WSL stuff with gpg-agent but I use the standard OpenSSH based ssh server on Windows on a daily base. It is actually part of our release build chain. A recent problem I encountered was fixed in master with rG2469dc5aae and should be backported to 2.4. Might be related to your problem but I need to read your detailed bug report more closely.

@werner Thank you for the response. Is there a nightly build or similar that I can grab from somewhere to see if using the latest master branch solves the issue?