The order to solve:

This is an experimental patch to support "Use-for-ssh":

cmd_keyinfo should be also updated to access the field correctly.

Also, it is better for a user, not to be asked confirmation (even if "Confirm:" is specified), that is, skipping the confirmation, when it is going to prompt the insertion of a card.

Editing a formatted password should work now as expected.

Its an issue of cursor position. If one either deletes or inputs a a character anywhere in the password string, the cursor always jumps to the end of the string.

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.

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 KexAlgorithms=-sntrup761x25519-sha512@openssh.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.

this looks similar to https://dev.gnupg.org/T5935 and https://bugs.debian.org/1008573

FWIW, your comments about the autostart script do not match with the running processes. Obviously, the autostart script starts gpg-agent with different command line options than the running process. My conclusion is that the autostart script isn't used. Or maybe it is started, but gpg-agent immediately terminates because it notices that another instance is already running.

If you add an autostart script then you may have to add a corresponding shutdown script as well, e.g. a script running gpgconf --kill all. You cannot expect that daemons, that you start via an autostart script, magically know when they should terminate.

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

Thank you for the hints!

Thank you for the explanation. (It's not related to --supervised, I suppose.)

I see the following GPG-related commands running currently (with disable-scdaemon in config file):

Please contact the Debian developers for any systemd/gnupg issues. We don't suggest the use of the --supervised option because it causes more problems than it claims to solve.

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.

Implemented.

What about at least accepting env variables OR tilde expansions? That will make it easier to integrate with dotfiles that intentionally use a home-dir based executable without having to pass the full path, so it could work cross platforms.

In T5783#153879, @werner wrote:

Sending a private key with just the local protection is not a good idea.

Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.

Saw this again and the commit was not in the Stable 2.2 branch. I have cherry picked it. This should resolve this issue.

@rupor-github no problem for the delay. Thanks for explaining!

@bernhard Sorry for the delayed answer, was on sabbatical.

@rupor-github no problem! :)

@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
on https://wald.intevation.org/forum/forum.php?thread_id=2359&forum_id=21&group_id=11

That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:

The show error is due a missing translation. What happened was that the translation was marked fuzzy and this marker was removed not realizing that the string really changed. The change was "...in the GnuPG system" -> "...in the %s system" which had been done to allow for different gpg names.

Start from scratch on a german system, even when you do a gpg --version it shows it is in german. Then import a PKCS#12 container and the dialog is in english.

A wild guess is that the different envvar systems we have in use are the culprit. It is anyway time to get this straight.

As suggested in the linked question on stackexchange, I think that even if the error comes from the pinentry program, GnuPG could echo a more informative error than gpg: decryption failed: No secret key, such as terminal to little to show the pinetnry program, or something similar.

Thanks for the report. Frankly the curses pinentries are not that widely tested.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

See T5267: Ed25519 backward compatible private key support for preceding ZERO(s) for the fix.

rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.

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.

If your problem is the incompatibility between standard OpenSSH (server) and PKIXSSH (client) for use of ssh-agent emulation of gpg-agent with ECDSA key, I'd suggest to apply following patch to your PKIXSSH:

diff --git a/compat.c b/compat.c
index fe71951..0c9b1ef 100644
--- a/compat.c
+++ b/compat.c
@@ -245,7 +245,6 @@ xkey_compatibility(const char *remote_version) {
 {	static sshx_compatibility info[] = {
 		{ 0, "OpenSSH*PKIX[??.*" /* 10.+ first correct */ },
 		{ 0, "OpenSSH*PKIX[X.*" /* developlement */ },
-		{ 1, "OpenSSH*" /* PKIX pre 10.0 */ },
 		{ 1, "SecureNetTerm-3.1" /* same as PKIX pre 10.0 */},
 		{ 0, NULL } };
 	p = xkey_compatibility_find(remote_version, info);

Unfortunately and confusingly, PKISSH returns "OpenSSH" when asked by "ssh -V".
Please install real OpenSSH, if this is the case for you.

Quote from IRC:
hey, i've some problems with my smartcard since quite some time. i'm not sure whether it's openssh related or gnupg. it's a openpgpcard v2.0 and i have to workaround ssh logins by using "SSH_AUTH_SOCK=0 ssh ...". .gnupg/gpg-agent.conf -