gpg-agent fails to sign request of PKISSH
Testing, NormalPublic

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

Related Objects

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!

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 a subscriber: gniibe.

Which SSH client are you using?

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.

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 renamed this task from gpg-agent fails to sign request to gpg-agent fails to sign request of PKISSH.Fri, Sep 27, 1:45 PM