In T5167#139880, @gniibe wrote:

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

There is no caching for smardcard PINs. Once a key (or group of keys) on a hard has been used (i.e. PIN entered). that key can be used as long as the card has not been reset or powered-down. No rule without exception: Some cards may require that a PIN entry is required for each crypto operation. For example the OpenPGP card (which is implemented on a Yubikey) does this for the signing key but not for the authentication (ssh) key. To disable this for the signing key you use the "forcesig" command of gpg --card-edit.

Removing 2.2 tag because it has been fixed in one of the last releases.

@werner can you confirm if the environment I provided will work with OpenSSH support fully implemented?

That code in gnupg has not been touched in a very long time so this may be caused by some side effect.

Fixed in Gnuk 1.2.16, although it still has a limitation by the I/O buffer size.

So, if there's no support for native OpenSSH yet, I'll wait for it. After it's supported, I should be able to get the scenery I described working, right?

Unfortunately you can't pass extra arguments.

Thanks for your information. No debug output any more, as I already figured out things.

In case of Ed25519 certificate signed by Ed25519 key with only few names and flags it seems to be just below 500 bytes. This could of course grow if names are added or larger public key is being signed.

@bvieira You need to set pinentry-mode=loopback for gpg program used in git.

Well, from the viewpoint of card specification, "a message M of arbitrary size" for Ed25519/Ed448 in RFC8032 is not good, because card has a limit for buffer size and the protocol in the OpenPGP card specification requires the steps of (1) the message M is buffered and then (2) the compute the signature.

I'm actually trying to do the following:

In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.

I just confirmed that Gnuk has a limitation for the input length is less than or equals to 256.
So, this is the issue of Gnuk, not GnuPG (or at least, Gnuk has the problem).

Please show us concrete example of debug output by scdaemon, when you run ssh-keygen.
You can have a setup in .gnupg/scdaemon.conf like:

I've meant scdaemon rather than OpenSC. I'll correct the descritpion.

gpg-agent has only very limited support for ssh certificates which is the reason that your command fails.

Any news on this?

Although I don't use the ssh client on Windows I had to integrate the Windows ssh server into our release process (GlobalSign sent us a Windows-only token, for the new cert and so we can't anymore use osslsigncode). The ssh server is really stable and so it makes a lot of sense to better integrate our ssh-agent into Windows.

@werner Yes, that sounds great, and would help already a lot, but extending it for card keys would be optimal. Thanks for your work.

In master (to be 2.3) you can add a Label: line into the sub key file of on-disk keys. I use this for quite some time now to show me alabel for my on-disk ssh keys so that I known which one was requested. We can and should extend this to card keys.

Also fixed for 2.2

I located the bug in agent/command-ssh.c.
Our practice is two calls of gcry_sexp_sprint; One to determine the length including last NUL byte, and another to actually fills the buffer.
The first call return +1 for NUL byte.
The second call fills NUL at the end, but returns +0 length (length sans last NUL).

Applied to master and 2.2. Thanks.

I think this patch should be backported to STABLE-BRANCH-2-2

I've just pushed 29adca88f5f6425f5311c27bb839718a4956ec3a to the dkg/fix-T4490 branch, which i believe fixes this issue.

And, i just discovered that when i manually edit the key to remove the (comment) list from the *.key S-expression file, the final --export-secret-key works fine. so the failure appears to be due to the presence of the (comment) clause. (same as in T4501)

I often put an extra nul byte at the end of binary data so that accidental printing the data (e.g. in gdb) assures that there is a string terminator. But right, it should not go out to a file.

I was trying to use the above technique to be able to generate an OpenPGP transferable secret key in an ephemeral homedir. Ephemeral directories are recommended in the GnuPG info page's "unattended usage" section, but they do not work here.

ssh does nut support brainpool curves and thus GnuPG does not know how to map its internal name of the curve to the name as specified by ssh. GnuPG supports these curves:

We had this idea to have a label: or similar item in the extended-key-format which is displayed in addition to the other info. The user can then use an editor to put whatever she likes into this field.

there should be clearer labelling of smartcards so that users can tell them apart more easily

@werner I was hoping to make a modified gpg-agent build that would let me walk through what's going on after the nonce is sent but it looks like the gpg4win process only takes in a package of pre-built gpg binaries which rules that out. As far as I can figure out, after the nonce is read and accepted, libassuan creates a stream object out of the socket and then finding nothing in the stream terminates the ssh handler. We send the actual client request immediately after the nonce but in a separate call to send() so I now wonder if by not having anything read in at the same time as the nonce gpg-agent or libassuan thinks that it's a 0-length stream.

I just took a look through assuan-socket.c and it appears that we just need to send the nonce and don't need to read anything back. We also found a bug on our side that was preventing the nonce from being sent, which has been fixed. The error message logged above no longer happens.

The nonce is a string of octets thus it needs to be passed verbatim. I would need to study the code in libassun/src/assuan-socket.c to tell more.

@werner After sending the nonce value from the socket file, does anything need to be read back before ssh-agent commands can be sent? Are there any byte ordering requirements for sending the nonce or can they be sent in the same order as they are in the file?

I've been working with one of Microsoft's developers on a temporary tool that should bridge the connection between named pipes and the Unix sockets emulation used by gpg-agent but things appear to trip up with sending the nonce. From the position of the tool, the nonce value is successfully sent (send returns 16), but never seems to be picked up by gpg-agent. Instead both gpg-agent and the bridge sit there until whatever tool is using them (I test using ssh-add -l) is terminated, at which point gpg-agent immediately spits up the message

Rhat's for the client, right. I never used it. We used to run a Windows 8 instance in a VM to run tests via ssh on it. That worked most not really stable. For obvious reasons I am more interested in the server part ;-)

Thanks. I took these patches and simplified them. Not test tested, though,.

I would argue that the Windows port of OpenSSH is not unstable at this point, especially given that Microsoft is even providing it as an installable feature in the next regular Windows 10 release. The fact that the port is now using actual OpenSSH version numbers instead of their own 0.x versions lends credence to this as well.

Thanks for the fix! however, the fix only addresses the two flags we currently know about. I've pushed a branch T3880-fix that tries to implement the If the agent does not support the requested flags […] It must reply with a SSH_AGENT_FAILURE message part of the spec.

It is in 2.2.6

Thanks for the pointer. But as long as the Windows ssh server is that instable I see no urgent need to add this to GnuPG.

Fixed in 273964798592cd479c111f47e8ce46d5b1999d6a.

Well, can you then please fix it?

Fixed as of 525f2c482abb6bc2002eb878b03558fb43e6b004.

Applied as ebe12be034f0.

While I can't reproduce this problem myself, I think I found an issue of gpg-agent passphrase caching.
Double free may happen when multiple threads enter agent_put_cache, for example.

In 2.1.19, gpg-agent uses getpeerucred for macOS. I changed it (since it seemed not working). In 2.1.20, gpg-agent now uses getsockopt with LOCAL_PEERPID.
It seems for me that the crash occurs by ucred_free. If this is the case, 2.1.20 fixes this issue.

I can reproduce this. Our test indeed feeds a passphrase to the agent.

Any thoughts or progress on this?

Adding %f does not help much because it is only used internally. I would be in
favor of adding an ssh-key-mode option so that the user can select the hash algo
and the output format.

John is using 2.1.14, but this bug was fixed in 2.1.15.

This is apparently just re-reported on gnupg-users:

https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056892.html

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

I do consider it a bug, at least because we did not signal an error to ssh-add.
Fortunately, this was easy to fix.

Fixed in 270f7f7b.

I would not consider this a bug. sshcontrol is used to enable certain keys for
use with ssh. Updating keys is useless if they are already available.

If you remove the keys from sshcontrol you disable them. I would suggest to put
a '!' in front of the keygrip instead of deleting the line in sshcontrol. This
allows to re-enable a key w/o problems.

The solution is to remove the key in private-keys-v1.d before running ssh-add.

http://superuser.com/a/1064269/216912