Page MenuHome GnuPG
Create Task
Maniphest T4563

gpg-agent fails to sign request of PKISSH
Open, LowPublic
Actions

Description

I have this error now for some time in my gentoo gnupg builds or from origin/master. The log reads

ssh sign request failed: Unknown option <GPG Agent>

so I hunted the code down to the ssh_handler_sign_request function that removes all known flags.
The error comes from flags != 0, so I started patching the code, by a measurement of what flags is in the end.

if (flags & 0x10000) {
  log_error ("strange flags in: 0x%x/%d\n", flags, flags);
  /* drop the strange flag */
  flags &= ~0x10000;
}

by such strange flags debug line I detected that the ssh client sets this 0x10000 flag, that is unknown to gpg-agent, so I added this little block above that filters this unknown flag.

Details

Version
gpg (GnuPG) 2.2.15

Event Timeline

ikrabbe created this task.Jun 7 2019, 2:05 PM
ikrabbe changed the task status from Open to Testing.Jun 7 2019, 2:09 PM

Please check if this patch works for you and please check where this flag actually comes from and what it does say!

gnupg.patch759 BDownload

ikrabbe triaged this task as High priority.Jun 7 2019, 2:12 PM

This is a high prio error, I guess, because it breaks a very useable part of gnupg, that is really hard to maintain. If it is not stable to sign keys with the gpg-agent, it is very hard to use that. Many might switch back to the ssh-agent.

• werner lowered the priority of this task from High to Normal.Jun 7 2019, 6:32 PM
• gniibe added projects: gpgagent, Info Needed.Jul 11 2019, 8:42 AM
• gniibe added a subscriber: • gniibe.

Which SSH client are you using?

ikrabbe added a comment.Sep 9 2019, 9:45 AM

Sorry for the late answer, but I have been busy. Actually this happened against several ssh versions, for some time now.

2019-09-09 09:29:07 gpg-agent[4285] ssh sign request failed: Unknown option <GPG Agent>
2019-09-09 09:29:07 gpg-agent[4285] ssh request handler for sign_request (13) ready
2019-09-09 09:29:07 gpg-agent[4285] ssh handler 0x7ff6c67b1700 for fd 10 terminated
ingo@krabbe ~ $ gpg-agent --version
gpg-agent (GnuPG) 2.2.17
libgcrypt 1.8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ingo@krabbe ~ $ gpg --version
gpg (GnuPG) 2.2.17
libgcrypt 1.8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/ingo/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

So the current SSH Version is OpenSSH_8.0p1-PKIXSSH-12.1, OpenSSL 1.0.2r 26 Feb 2019.

ikrabbe added a comment.EditedSep 9 2019, 10:18 AM

But this problem remains for several versions for some time. I tried to find out the source of this "new option" in the communication, but I could not find anything about "GPG Agent" in the source code of openssh.

On the other hand: How should the ssh client emit an option that says "GPG Agent", that is not within the domain of ssh. Or not how, but better why. But such logic dependencies are importet to more and more software projects these days anyway. We should really try to get rid of such over developed proptocols (ssh is one of such protocols of course).

What is the reason to reject unknown options anyway, on gpg-agents side?

It is often more usefull to just warn about such additional options and just ignore new protocol features, to be most compatible across time and software versions.

I found that OpenSSH_7.5p1-hpn14v12lpk, OpenSSL 1.0.2r 26 Feb 2019 works.

• gniibe added a comment.Sep 27 2019, 8:23 AM

OK, I identify the problem.

First of all: The protocol is defined in: https://tools.ietf.org/html/draft-miller-ssh-agent-03

The particular usage of flag is apparently the non-standard one of PKIXSSH: https://gitlab.com/secsh/pkixssh
It is defined as SSH_AGENT_RFC6187_OPAQUE_ECDSA_SIGNATURE in the implementation, but it seems that no documentation is available.

I think that it is for ECDSA, requiring different format for signature. The certificate format of PKISSH is defined here:
https://tools.ietf.org/html/rfc6187

I guess that, from ssh-agent point of view, signaturess by x509v3-ssh-dss, x509v3-ssh-rsa, and x509v3-rsa2048-256 are compatible to existing implementation/protocol of ssh-agent between original SSH.

Reading RFC-6187, it looks like one by x509v3-ecdsa-sha2-* is also compatible.

So, I don't understand the reason why there is a new flag of SSH_AGENT_RFC6187_OPAQUE_ECDSA_SIGNATURE for that.

When SSH_AGENT_RFC6187_OPAQUE_ECDSA_SIGNATURE is used, gpg-agent fails. For me, it is correct behavior.
Don't put such an incompatible flag, if it is not needed. If the signature format is different, it fails at another place.
This is my opinion.

• gniibe edited projects, added Feature Request; removed Info Needed, Bug Report.Sep 27 2019, 10:17 AM
• gniibe renamed this task from gpg-agent fails to sign request to gpg-agent fails to sign request of PKISSH.Sep 27 2019, 1:45 PM
idl0r added a subscriber: idl0r.Dec 9 2020, 12:04 PM

Hey,

I am affected by the same bug and the patch seems to work for me. Login via gpg-agent with ssh support is possible again, which wasn't before, since some openssh and/or gnupg update. Not sure.

• gniibe lowered the priority of this task from Normal to Low.Dec 14 2020, 3:19 AM

In theory, I don't think the patch gnupg.patch works. It just ignore the flag.

The undocumented implementation flag SSH_AGENT_RFC6187_OPAQUE_ECDSA_SIGNATURE is used to have different incompatible format for ECDSA signature.
In the original x509-v3-cddsa-sha2-*, it uses SSH's mpint of (r,s). On the other hand, with the flag is specified, PKISSH uses DER format.

I looked the code of PKISSH.
I think it is PKISSH, which requires a fix of compat.c: https://gitlab.com/secsh/pkixssh/-/blob/master/compat.c#L238

When, the remote server is OpenSSH, it wrongly sets SSHX_RFC6187_ASN1_OPAQUE_ECDSA_SIGNATURE flag, which is not supported by usual implementations of ssh-agent.

Anyhow, it means that the flag SSH_AGENT_RFC6187_OPAQUE_ECDSA_SIGNATURE has not been used at all, and better to be removed from PKISSH.
So, I lower the priority of this bug.

idl0r added a comment.Dec 14 2020, 9:04 AM

Well, I have no idea about the technical background to be honest but without this patch it doesn't work at all for me, unless I stop using the agent or workaround it by using SSH_AUTH_SOCK=0. With this patch, I can use the agent again. I don't know how many others are affected by this but it made it usable again, which wasn't the case for months already.

• werner added a subscriber: • werner.Dec 14 2020, 10:09 AM

I do not think that we should support a fork of openssh right now. If we would support it we are bound to maintain that for years - this is not a good idea.

idl0r added a comment.Dec 14 2020, 10:16 AM

I was and I am using OpenSSH on both sides, client and server.

• gniibe added a comment.Dec 14 2020, 10:20 AM
In T4563#140184, @idl0r wrote:

I was and I am using OpenSSH on both sides, client and server.

Then, you are writing wrong place. This is a ticket about imcompatible feature of PKISSH.

• gniibe added a comment.Dec 14 2020, 10:23 AM

I added "Feature Request", because this is a request to support:

  • A feature of bug compatibility, which is implemented wrongly in PKISSH
  • for a specific algo of key, which is not considered so useful (== ECDSA)
  • PKISSH, which is variant of OpenSSH

A user can

  • use EdDSA key, instead
  • ask a fix to PKISSH
  • use standard OpenSSH
idl0r added a comment.EditedDec 14 2020, 10:26 AM

Yeah but it seems to be the same issue / reason. I wasn't aware that PKISSH is something else. I thought it was an extension/protocol or something

idl0r added a comment.EditedDec 14 2020, 10:31 AM

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 -

gpg-agent.conf158 BDownload
the debug log:
debug.log2 KBDownload
esp. "ssh sign request failed: Unknown option <GPG Agent>" and ssh says "sign_and_send_pubkey: signing failed: agent refused operation"
gpg --edit-card and --card-status works fine and sign/encrypt works fine as well. only ssh auth fails
openssh 8.1_p1, gnupg 2.2.20

It also affected non-smartcard keys tho

And it just turns out that Gentoo seems to use this PKISSH stuff for X.509 support
% ssh -V
OpenSSH_8.1p1-PKIXSSH-12.3-hpn14v20, OpenSSL 1.1.1g 21 Apr 2020
:(

• gniibe added a comment.Dec 14 2020, 10:52 AM

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

• gniibe added a comment.EditedDec 16 2020, 12:58 AM

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);

IIUC, "PKIX pre 10.0" uses the incompatible format for ECDSA signature (DER, not OpenSSH) and PKIXSSH didn't have any version string "PKIX" at that time. Those two mistakes has been fixed in 10.0.
To support this mistake compatibility of "PKIX pre 10.0", the flag exists, but it is only for "PKIX pre 10.0", and... unfortunately, it has bad effect when using with standard OpenSSH.

The patch above removes the support of "PKIX pre 10.0" mistake, for better interoperability with standard OpenSSH.

• gniibe closed this task as Wontfix.Dec 16 2020, 1:42 AM
• gniibe reopened this task as Open.
• gniibe claimed this task.