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 fixit):

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? 🙏

[maxgoedjen]

@mortax basically if someone is interested in adding it, I'm not super opposed, but right now the SEP doesn't support non-EC keys so parity in that regard has been low priority. Can you tell me a little more about your use case? Does it require an RSA key, just a preference, etc? Basically up til now I've just been recommending using EC keys on YubiKeys as well.