sign_and_send_pubkey failure when attempting to ssh using the Secretive public ssh key

[mortax]

i'm using secretive with the Personal Identity verification diver using the Key For PIV Authentication to ssh.

i have been trying to understand why this happens (and how to fix it):

debug1: Server accepts key: rsa-sha2-512 RSA SHA256:<snip> agent
debug3: sign_and_send_pubkey: using publickey with RSA SHA256:<snip>
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:<snip>
sign_and_send_pubkey: signing failed for RSA "rsa-sha2-512" from agent: agent refused operation
debug1: Offering public key: /Users/jrd/.ssh/id_rsa RSA SHA256:<snip2>

the key is accepted by the server but not used by ssh. ultimately, i think the answer may be in README.md:

A Note Around Code Signing and Keychains

While Secretive uses the Secure Enclave for key storage, it still relies on Keychain APIs to access them. Keychain restricts reads of keys to the app (and specifically, the bundle ID) that created them. If you build Secretive from source, make sure you are consistent in which bundle ID you use so that the Keychain is able to locate your keys.

i think this means that ssh can't read the key and therefore i won't be able to ssh using the ssh public key returned by Secretive (via ssh-add -L). am i missing g anything?

[maxgoedjen]

It's probably less that, more that it's an RSA key. They're theoretically supported since #450, but TBH it's a pretty untested flow. The keychain access stuff isn't particularly applicable to the smartcard API – Secretive actually doesn't create any keys on smart cards and relies on management apps like YubiKey Manager to do that.

[mortax]

thanks. we're digging into this more deeply and seem to be making incremental progress. i'll report back when i know something definitive.

[mortax]

@maxgoedjen i now understand how this happens. it appears that your supposition regarding the immature support for RSA keys is correct,

the macOS Security Framework (aka the Keychain API) represents EC keys in binary form, which is the same as the way OpenSSH represents them. unfortunately, that's not so lucky for RSA. the Keychain API represents RSA keys in ASN.1 DER encoding, but OpenSSH represents them as a sequence of two OpenSSH mpints. thus in the EC case, Secretive can just pass what it gets verbatim. for RSA, however, Secretive needs to decode the ASN.1 and re-encode it as mpint. It isn’t doing that — it is just passing it verbatim in both cases.

let me know what you think about that. any chance this is something you are willing to address? i might be able to submit a PR to address this -- but it might take me some time to come up to speed on the code enough to submit a worthy change.

[mortax]

any thoughts @maxgoedjen? 🙏

[mortax]

@maxgoedjen i'm reviving this thread now that i have everything building (thanks!) and have had time to look into this. our use case is very simple: i have a smart card, e.g. Yubikey, that has an ssh-rsa key on it. i'd like to use Secretive as the authentication agent for ssh.

unfortunately, Secretive sees the card and the key but retrieves it and/or transmits the wrong values to ssh. the person who knows the most about this is out of town so i just spent the last three days trying to translate his analysis:

thus in the EC case, Secretive can just pass what it gets verbatim. for RSA, however, Secretive needs to decode the ASN.1 and re-encode it as mpint. It isn’t doing that — it is just passing it verbatim in both cases.

into a bug fix. i tried tweaking multiple parts of Secretive to 'fix' the values (paying attention to the changes made in #450). i hoped it would be as simple as taking the value returned by SecKeyCopyPublicKey and decoding the ASN.1 encoding. i first tried that with my own function and then later using the seemingly perfectly suited SecKeyCopyExternalRepresentation. so close and yet neither worked.

here's an example of Secretive getting it wrong.

using the build in OpenSSH authentication agent:

[zimbo]$ ssh-add -l
2048 SHA256:3Iijb37rTZvHKRqB6KBUAO/su1FJCCqeUSojt4lzv30 yubikey
[zimbo]$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCT/5mv/KNwqRpySt2+5hZzTzKHBPnWAw3i/XNMwm4bGqDX6D6EYEFvDPWi+z+hygLZnWM/j55wLtIfAcs/Y/ixRs80BtxPVJiWbA2LzsswhOABRVILsoFRefXmILJsE4IjCaGTkuWdarpD8r9FSYOqxOXuBoyaI/Js2Gm+83xWszmVdI1rjqSBf5bQeTGyOsSp9pLmmW3VFazK3QAuXawD4q4GL2kNgKByStJHAJMbh+VhAkD45qBQNCnSPxPAsuNfdxApOLkxCEqoe7n+EQFh1R2RtrUSS4nbaRFJ+iDR5loRnoz5CKMeH7Jivh5Zs+OkARQp5jvEjqtSbX73ZfXp yubikey

via secretive:

[zimbo {SecretAgent}]$ ssh-add -l
2158 SHA256:ALVVRZgbQqJ1q0u4YahTrX50mBZ7/aQGKh1VQWvebCQ rsa-sha2-512 (RSA)
[zimbo {SecretAgent}]$ ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAAMcnNhLXNoYTItNTEyAAABDjCCAQoCggEBAI30JzCMqBS6m8/h4P2QM8BNB5blPoY4Ilyct/P3GwCz9MEdGPR51+x50W40cxDqpR+QdF0M2Yqkl9ibmuE/kXXGav+H4biy4aC+9GcOb3GUZZtt9tn2E/SM0eHcAbvb6DYrKbpinwQk6chUYft5754ujz5S50/xGEY7iNdUkaiGJe1u/IAwCIFeviLpp3MYLav0snA0648BbMhxTjfKBzlul8vh3o55JhGsB92l9qqw3Y1HgSxcpLjbgucSi/er6HFlh3foVswL0n5wxMYAL5xppOGvYezQW758HxhxSzLrnNq1C3r+wUbCVWeY0ww5ltuWKdG8HHIdQHPBxMOWVQUCAwEAAQ== rsa-sha2-512

tl;dr: i'm curious if you can provide any pointers into where i might look to correct the issue. i can't spend any more time guessing and experimenting. worst case, i will need to wait to revisit this until the SME returns in a month. 🤞

[mortax]

@maxgoedjen let me know if you won't be able to comment on this. without a pointer (or two) i will shelve it for a month when i should be able to get help for the person who tracked down the issue.

[mortax]

@maxgoedjen let me know if you have any thoughts (even if you can't help).

[maxgoedjen]

TBH this is a pretty under-developed area of Secretive (basically only there because I thought we were getting it for free) – I don't really have any advice beyond just really getting into the SSH-agent spec unfortunately.

[mortax]

cool. thanks. i'll dig into it again at the end of the month a see what i can find. i don't think it will be a big change but i'll wait until i will have a little extra help.