Tue, May 3
Nitrokey Start uses Gnuk as its firmware. You need to upgrade its firmware to version 1.2.16 or newer.
Please note that when upgrading the firmware, your keys will be removed.
Mon, May 2
Its a nitrokey start. I gave it another spin just to make sure, and again when updating to openssh 9.0 and "gpg (GnuPG) 2.3.6-unknown", it fails (again with careful gpgconf --kill gpg-agent etc. Double checked the downloaded source code by arch's makepkg, appears to have that patch applied. Also tried adding -o KexAlgorithmsemail@example.com to the ssh command, which didn't help.
Please describe what token is used. For my use cases with rGe8fb8e2b3e66: scd: Don't inhibit SSH authentication for larger data if it can., both of Gnuk (>= 1.2.16) and Yubikey (>= 5) work well.
Fri, Apr 29
Thu, Apr 28
FYI, I built 2.3.6 using a modified archlinux PKGBUILD (& disabling patches to avoid conflicts), then did:
gpgconf --kill gpg-agent
gpgconf --launch gpg-agent
but ssh still fails as before
Tue, Apr 26
My Yubikey (Yubico.com Yubikey 4/5 OTP+U2F+CCID) works fine with OpenSSH using kex of firstname.lastname@example.org.
Mon, Apr 25
Sorry, I was confused. For RSA-4096, data is hashed by gpg-agent and hashed data is signed by a card.
We are using rsa-4096 on smartcard for quite some time; so I wonder what's the problem here. Is that that we don't use our Assuan hack for large key material with OpenPGP.3?
There is another case: RSA-4096 key. scdaemon rejects data by Invalid value. Unfortunately, there is no fix for this, as it's really too large. Even if scdaemon allows larger data, the card implementation rejects, when it conforms to PKCS #1 standard (data should not be larger than 40% of the modulus).
Fri, Apr 22
I confirmed that the patch above works with newer Gnuk (>= 1.2.16).
Thu, Apr 21
Apr 14 2022
I have not yet tested OpenSSH 9 and thus the patch to master is here just as a test. Please better use gnupg 2.3 (stable) instead of 2.2 (LTS) because it is unlikely that we will backport all this new ssh stuff.
Feb 8 2022
It would be awesome if you could implement this \o/
Jan 28 2022
Thanks for the report. To keep things easy the empty comment is now translated to "(none)".
Jan 21 2022
Jan 10 2022
Nov 23 2021
Nov 16 2021
Nov 15 2021
Adding the check on host side, I pushed the change: rGa575b0aba542: scd:openpgp: Support longer data for INTERNAL_AUTHENTICATE.
Nov 12 2021
Oct 13 2021
@rupor-github no problem for the delay. Thanks for explaining!
Oct 12 2021
@bernhard Sorry for the delayed answer, was on sabbatical.
Sep 29 2021
@rupor-github no problem! :)
Sep 28 2021
@bernhard thank you for explaining, did not mean to offend anybody. Before creating win-gpg-agent I tried to read as much as I could on a history and obviously had to study source a bit. Be it as it may - I decided to have separate wrapper, rather then contributing directly to gpg code base. There is noticable number of use cases on Windows which presently not addressed, some I believe are sitting it the queue already.
@rupor-github thanks for your explanations and the contribution to the GnuPG and crypto Free Software code base!
Since Windows user naively could expect multiple methods of accessing certificates from different programs (or sometimes from the same program but different supported environments, like Git4Win and git in WSL) to work together transparently, win-gpg-agent covers translation of one accidentally supported method (32 bit putty shared memory) to multiple unsupported ones (named pipe, cygwin, etc). It also takes care of managing gpg-agent.exe lifetime tying it to user login session for convenience. It uses command line parameters to only to overwrite staff critical to its functionality and does not prevent user from having configuration file(s). Optionally it provides pinentry which is integrated with Windows native Crypto Vault and UX rather than using wonderful QT or GTK. As specified in documentation when developers of gpg and WIndows will get their act together and figure out what they want and how they want it - most of functionality would not be needed. I would like to point out that simply claiming superiority and not supporting cygwin (Git4Win) or working Assuan ssh socket or putty shared memory in 64 bits Windows build does not help with user experience a single bit.
Lots of detailed documentation but frankly, after a brief read I have not yet figured out what it really does. We won't support Cygwin stuff - this is all obsolete and awe also removed starting gpg-agent as a service for good reasons. Instead of starting gpg-agent with lot of command line args it would be better to put this into a per user or system wide config file.
There is a user report that got things to work with https://github.com/rupor-github/win-gpg-agent
Sep 13 2021
Sep 9 2021
How difficult would it be to teach gpg-agent to fall back to another SSH agent if given an unsupported key?
Aug 13 2021
Jun 18 2021
ggp-agent has no support for U2F and it can't work with these key types. Given that Yubikeys also have proper keys (even eddsa) I doubt that we will implement support for ecdsa-sk OpenSSH feature any time soon,
Feb 17 2021
Feb 10 2021
Jan 8 2021
Jan 7 2021
I'm also getting this same error with GPG4Win 3.1.14.
Jan 6 2021
I wrote https://github.com/rupor-github/win-gpg-agent to simplify usage on Windows until this issue is resolved - it handles various edge cases on Windows.
Jan 5 2021
Dec 23 2020
Already have set another, thanks gnibe! See ya!