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

Thanks. Commited to master.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.

Missed some, will post an updated patch.

I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.

Thanks for reporting. We usually test by moving the <keygrip>.key files around ;-)

Sure, but this will need adaption in FIPS mode as it fails with:

Patch using SHA1 instead of MD5.

There are other uses of MD5 and thus we can't disable it. For example gpgsm also lists the MD5 fingerprint of certificates because they are still in use at some places.

Sorry, it looks like no problem.

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.

In T5931#165009, @alexk wrote:

A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:

KexAlgorithms -sntrup761x25519-sha512@openssh.com

For me ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com ... does work as well.

A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:

I've got a similar patch, but I'm not sure it's any better -- I'm adding EcDSA support for cards (via gnupg-pkcs11-scd) and with this patch I can sign subkeys and data.

The problem here is how large the data to be signed is. It is an issue of protocol design. The protocols are explained in openssh/PROTOCOL.certkeys and openssh/PROTOCOL. Unfortunately, it seems that it was designed with not much consideration for smartcard use case, so, data to be signed may be longer (than the capability of smartcard).

Sadly, it doesn't work for me. But thank you.

I managed to find a way to minimize the data (less than the one on Oct 25).
And it somehow works for me.

So what should I do now? Should I report it to OpenSSH team?

Meanwhile I have _some_ doubts that the v5 format is a good idea. It will introduce a lot of problems and thus a more lean way of replacing the fingerprint should be re-considered. Even if that means, we have to live with two kinds of fingerprints for a decade or so.

Given that the OpenPGP WG practically decided to fork OpenPGP I don't see a reason why we should keep this bug open.

Will go into 2.3.9 and gpg4win 4.0.5

Has been release quite some time ago (2.3.8 and earlier)