Mon, Jan 30
Those "curated keyrings" and keyservers don't work together. The whole idea of automated but curated keyrings is dead end.
Thu, Jan 19
Tue, Jan 17
I am very sure that this is resolved and we support that in Kleopatra.
Dec 22 2022
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
Dec 21 2022
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
Dec 20 2022
Note that in-source-tree builds are broken - see T6313
Release done
Dec 19 2022
To be released tomorrow.
Dec 16 2022
@raysatiro: Please re-open if you are able to give us a reproducer
Dec 15 2022
Thanks. Commited to master.
Dec 14 2022
Dec 13 2022
Missed some, will post an updated patch.
Dec 12 2022
Dec 9 2022
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.
Dec 6 2022
Dec 1 2022
Thanks for reporting. We usually test by moving the <keygrip>.key files around ;-)
Nov 30 2022
Nov 29 2022
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.
Nov 25 2022
Sorry, it looks like no problem.
Implications are... you won't be possible to use new protocols introduced by newer OpenSSH:
Nov 24 2022
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)
Nov 22 2022
I tested with openssh 9.1. When I add -o PubkeyAuthentication=unbound, I can make the length of data smaller.
Nov 17 2022
Nov 9 2022
A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config:
Nov 2 2022
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.
Nov 1 2022
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).