I located the bug in scdaemon.

Using the primary key for ssh was not intended and thus not tested. I have not yet found the time too look closer at your report. Just one remark:

Thanks for that info. I tag it as FAQ and change the subject in case someone searches for such a problem.

Fixed in 2.5.2.

Closed, since this was documentation for the workaround, four years ago.

Just a reminder: with Gnuk 1.2.15 and an ed25519 key PubkeyAuthentication unbound is required for hosts using the new feature.

In case if someone finds it through a search:

Closing due to age and because gpg4win 4 started to using the much improved GnuPG 2.4

Here's another data point.

See the the commit for a description of the changes.

@MathiasMagnus This change is to support Win32-OpenSSH by gpg-agent emulation of ssh-agent; You can use gpg-agent emulation of ssh-agent when you use Win32-OpenSSH. That is, you can use GPG auth subkey for Win32-OpenSSH.

@gniibe Am I misunderstanding something? I thought that with this change one is able to connect from a Windows box to a Linux box and have GPG agent forwarding work. I am still hitting pretty much the same issue described here: https://github.com/PowerShell/Win32-OpenSSH/issues/1564
On my Windows endpoint I'm running gpg.exe version 2.4.0.49237 and in C:\Users\mate\AppData\Roaming\gnupg\gpg-agent.conf I have a single line enable-win32-openssh-support. Running gpg-connect-agent.exe reloadagent /bye I have a gpg-agent running. Get-Process gpg-agent shows that it's running. In my Windows env I have SSH_AUTH_SOCK set to \\.\pipe\openssh-ssh-agent and my Linux endpoint is configured in SSH config with

ForwardAgent yes
AddKeysToAgent yes
RemoteForward /run/user/1015/gnupg/S.gpg-agent C\:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra

As the remote end reports /run/user/1015/gnupg/S.gpg-agent that socket for agent-socket when issuing gpgconf --list-dirs and my local gpgconfg.exe --list-dirs reports C%3a\Users\mate\AppData\Local\gnupg\S.gpg-agent.extra where I transform %3a to \: manually. SSH authentication works perfectly, when connecting pinentry-qt pops up to unlock my key and when connecting to yet another machine, my SSH agent is forwarded again. However, gpg fails to use my agent. Issuing gpg --list-secret-keys --verbose prints the following to the console:

gpg --list-secret-keys --verbose
gpg: using pgp trust model
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: waiting for the agent to come up ... (5s)
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
getsockopt SO_ERROR failed
connect_to C:/Users/mate/AppData/Local/gnupg/S.gpg-agent.extra port -2: failed.
gpg: waiting for the agent to come up ... (4s)
gpg: waiting for the agent to come up ... (3s)
gpg: waiting for the agent to come up ... (2s)
gpg: waiting for the agent to come up ... (1s)
gpg: can't connect to the agent: End of file

What is missing to tie the knot on both ends without having to resort to 3rd party tools like @rupor-github 's agent-gui? The remote gpg version is 2.2.19, is that the issue? Must that also be 2.3.9+?

Let's first collect all keys, assign a priority, sort, and only then send them back to ssh.

Thanks all. It is a bug in Win32 OpenSSH. https://github.com/PowerShell/Win32-OpenSSH/issues/1953 it is already fixed. I think the issue will be resolved after the update is shipped. I could use ssh -T git@github.com as a workaround.

Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0

This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.

Authentication succeed if I pressed enter after:PTY allocation request failed on channel 0

I try WinGPG 4.1.0, and I receive an error:
ssh git@github.com
PTY allocation request failed on channel 0

Implications are... you won't be possible to use new protocols introduced by newer OpenSSH:

Thanks. Adding 'PubkeyAuthentication unbound' to my ~/.ssh/config seems to workaround it for me on openssh-9.1p1-3 (arch). I don't quite follow what the implications of that setting are though.

In my cases (tested with 9.1), here are the length of data to be signed by ssh-agent (emulation by gpg-agent).

• 164 bytes: Both features disabled by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com -o PubkeyAuthentication=unbound
• 192 bytes: Unbound only by: ssh -o PubkeyAuthentication=unbound
• 298 bytes: No Post Quantum only by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com
• 330 bytes: Both features enabled (no options)

I tested with openssh 9.1. When I add -o PubkeyAuthentication=unbound, I can make the length of data smaller.