In T5444#146395, @werner wrote:

You should anyway use --quick-gen-key.

This is still broken on 2.5.5.

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.

I just wanted to report that I'm having this issue on Fedora 39, with GnuPG version 2.4.4.
I'm being asked for the PIN for every operation (Sign, Decrypt, Authenticate) I'm having this issue on 2 different laptops using YubiKey 5C NFC and YubiKey 5C Nano (Firmware version: 5.4.3).
I tried disabling PIV (disable-application piv) and then PIN caching started working again, so I just wanted to report this as it's marked as resolved.

Interesting. So the problem is not actually the Key-Type, but that the default key-type requires a Key-Curve parameter which has no value by default

It works in 2.4.4 if you add

I recently stumbled upon this as well.

I sued the done column because we have not assigned it to any milestone.

Fixed a long time ago.

In T4393#180500, @andrewgdotcom wrote:

Perhaps we need to open a new issue for this, to keep the discussion more focused?

@bernhard Following up on discussion elsewhere:

With VS-Desktop-3.2.0.0-beta214 and Gpg4win-4.2.1-beta31 the error is "Bad Passphrase" in this case.
I do not see a reason why this ticket is still open.
The already resolved Kleopatra Task T5713 is probably a duplicate of this one.

Dear Werner, have you had any toughts about this ?

@gniibe I have submitted D565 to change the error message on curses initialization to "Required environment variable not set"

Those "curated keyrings" and keyservers don't work together. The whole idea of automated but curated keyrings is dead end.

I am very sure that this is resolved and we support that in Kleopatra.

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

Note that in-source-tree builds are broken - see T6313

Release done

To be released tomorrow.

@raysatiro: Please re-open if you are able to give us a reproducer