Make it possible to get a public key from the name chosen in Secretive via shell/CLI

[ari-becker]

At the moment, ssh-add -l only shows the hash of the keys added via Secretive, but no metadata (like the name of the key). The data under ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys is junk.

If I want to write a script that adds a particular key to the remote, then I need to already know the fingerprint of the key I created, which is less convenient than having a convention for key names and fetching the correct key via its name.

[maxgoedjen]

Hey @ari-becker there's a few reasons for this right now:

• The hash is the canonical unique identifier for the secret. Other fields (particularly names) do not have uniqueness constraints, so it's entirely possible and valid to have two keys with the same name right now (whether or not that was a good idea is certainly debatable, but that is a setup people do have in the wild right now)
• The PublicKeys directory wasn't really designed for this use case – it was much more "I want to be able to specify this key to be used with this site in my SSH config file."

Overall, basically Secretive is not designed to be managed from a CLI currently. A few people have requested that over the years so it's kind of on my radar, although not with any particular timetable now. If you have specific thoughts on what an ideal CLI interface for your specific use case would be, I'd be interested in hearing it.

[ari-becker]

@maxgoedjen

* The hash is the canonical unique identifier for the secret. Other fields (particularly names) do not have uniqueness constraints, so it's entirely possible and valid to have two keys with the same name right now (whether or not that was a good idea is certainly debatable, but that is a setup people do have in the wild right now)

Ah, I see.

Overall, basically Secretive is not designed to be managed from a CLI currently. A few people have requested that over the years so it's kind of on my radar, although not with any particular timetable now. If you have specific thoughts on what an ideal CLI interface for your specific use case would be, I'd be interested in hearing it.

Basically I'm trying to write a bootstrap / new-hire / new-laptop kind of script, something like:

brew install secretive
secretive create-new-key --username "$(whoami)" --label "super-special-bootstrap"
gcloud compute os-login ssh-keys add --key-file=$(secretive get-key-file --username "$(whoami)" --label "super-special-bootstrap")

But at the moment this appears to be a non-automatable segment, where I need to ask the user to go do some stuff manually, which is kind of a bummer and more likely to fail compared to running ssh-keygen directly (which is less secure than Secretive).

[torarnv]

I was looking at this today, trying to use ssh-copy-id to copy my public key to another machine. There's two issues right now:

• The public key in ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys doesn't have a corresponding private key file (as that's managed within the secure enclave), but ssh-copy-id expects one to be able to check if the key has already been added.
  • This can be worked around by having an empty file for the private key
• Pointing ssh-copy-id to keys in ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys requires granting Terminal.app/iTerm2.app permission access to data of other applications. This is due to the terminal app being the "responsible process" of the child processes it runs (zsh, ssh-copy-id, etc).
  • This is an issue also when symlinking the files from ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys into ~/.ssh.

Having to give Terminal.app/iTerm2.app full access to other applications is not ideal, as it means any other process that you run in the terminal (or any of its children) also have that access to these apps.

A solution that might solve this is to add an option in Secretive to write the public key (and empty private key) into ~/.ssh. This would require letting the user choose the location via a file dialog, which then gives Secretive access to that folder. The access can be persisted and shared between the Secretive agent and UI via bookmarks, as described here.

Has this been considered?

[martinpaljak]

For the original issue of mapping key labels to keys, adding the key name as comment to the .pub file the same way it is in the copy-enabled screen section of Secretive could help, and be easy to accomplish ? grep -l $keyname /Users/$USER/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/*.pub