Configure ability to add Identity Agent unix sockets for clients with multiple keys.

[dexterp]

Problem Statement

While Trying to add 3 or more keys to Secretive, I found that Github will only process a maxium of 2 SSH keys before it terminates the connection.

This is an issue when one has multiple ssh keys for different accounts.· For my case have·

1. Personal Github ssh key
2. A work Github ssh key
3. Bitbucket ssh key
4. A home network authentication SSH key
5. Others...

OpenSSH seems to randomly choose which two ssh identity keys are picked first. This means that if the identity needed is after the cutoff authentication will fail.

OpenSSH also has a default number of times before it will stop trying additional SSH identities.

Feature Request

Add ability to specificy alternate Unix domain sockets for selected keys. OpenSSH can then be configured with IdentityAgent <path> for specific hosts.

[maxgoedjen]

@dexterp interesting – I'll keep that on my radar. In the short term though, I THINK you should be able to accomplish this by following the instructions in https://github.com/maxgoedjen/secretive/issues/117

[dexterp]

Thanks, I didn't realise that the IdentityFile could be used with a public key.

I added another feature request #191, I do this myself if I knew Swift but I don't unfortunately.

[ad8-bdl]

There is another use case for supporting associating keys with distinct SSH_AUTH_SOCK sockets: agent forwarding. At present if I forward the agent socket to another host, as is common in bastion-type access, then all Secretive keys are available via the forwarded connection (see demo below). The "Require auth with each use" feature somewhat mitigates this risk for keys so configured, however it's better to outright segregate keys rather than relying on the user to correctly authorise the right key each and every time.

The usual way to avoid this exposure is to run another agent instance that holds only the keys that are desired to be available to the remote system - the remote system can't attempt to use what it can't access. For Secretive, it would be useful to have some sort of "virtual agent", whereby the user could set the agent socket appropriately and have only a subset of Secretive keys available. In the UI, I envisage a (single-level) "folder" that represented each 'virtual agent', something like

Secure Enclave
    Default
        key1
        key2
    Agent1
        key3
    Agent2
        key3
        key4

where Default/Agent1/Agent2 represent distinct "agents" (would be good to be able to label them: "Sourcetree", "CLI", "project X bastions"). For some use cases it would be nice but not essential to allow a key to exist in multiple agents (e.g. a graphical DVCS client might need the same key that is also used along with others by a CLI ssh connection).

Demo of the problem:

• Secretive has two keys, supersensitive ("Require auth with each use", pubkey ends in pDV4=), everyday ("auth not required when unlocked", pubkey ends in 1T1c=)
• gw is a bastion host whereby I need to forward everyday but has no business with supersensitive
• in the example below, use of the supersensitive key is blocked iff I have the presence of mind to deny its use; it would be far preferable if it weren't even exposed in the first place
• if I have multiple 'everyday' keys for different activities things aren't so rosy: a malicious actor could quite readily use any "auth not required when unlocked" key available in Secretive without me being any the wiser; to be clear this is certainly no worse than with the regular ssh-agent except it's possible to run multiple instances of that

% echo $SSH_AUTH_SOCK 
/Users/username/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh
% ssh-add -L | grep 'pDV4=' > /tmp/supersensitive.pub
% ssh-add -L | grep '1T1c=' > /tmp/everyday.pub
% ssh -F /dev/null -i /tmp/supersensitive.pub -A admin@gw
...
admin@gw:~$ ssh-add -L 
ecdsa-sha2-nistp256 AAAA...pDV4= ecdsa-sha2-nistp256       # I'd really prefer this not to be here at all
ecdsa-sha2-nistp256 AAAA...1T1c= ecdsa-sha2-nistp256
admin@gw:~$ ssh-add -L | grep 'pDV4=' > /tmp/supersensitive.pub
admin@gw:~$ ssh -F /dev/null -i /tmp/supersensitive.pub sensitivehost
# and Secretive's SecretAgent pops up a request to use the key, so that's good

[everpeace]

Hi, ssh-agent-filter can select a private key from the upstream ssh-agent.

ssh-agent-filter ships helper script afssh this can

❯ ./afssh --help
normal usage: afssh [ssh-agent-filter options] -- [ssh arguments]
interactive:  afssh -- [ssh arguments]

Usage: ssh-agent-filter [ OPTIONS ]
Options:
  -A [ --all-confirmed ]             allow all other keys with confirmation
  -c [ --comment ] arg               key specified by comment
  -C [ --comment-confirmed ] arg     key specified by comment, with
                                     confirmation
  -d [ --debug ]                     show some debug info, don't fork
  -f [ --fingerprint ] arg           key specified by pubkey's hex-encoded md5
                                     fingerprint
  -F [ --fingerprint-confirmed ] arg key specified by pubkey's hex-encoded md5
                                     fingerprint, with confirmation
  -h [ --help ]                      print this help message
  -k [ --key ] arg                   key specified by base64-encoded pubkey
  -K [ --key-confirmed ] arg         key specified by base64-encoded pubkey,
                                     with confirmation
  -n [ --name ] arg                  name for this instance of
                                     ssh-agent-filter, for confirmation puposes
  -V [ --version ]                   print version information
Environment:
  SSH_AUTH_SOCK  socket of upstream ssh-agent
  SSH_ASKPASS    command to run for confirmation questions

usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
           [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
           [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
           [-i identity_file] [-J [user@]host[:port]] [-L address]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] destination [command [argument ...]]

Thus, you can

❯ export SSH_AUTH_SOCK=<secretive agent socket path>
❯ afssh -f <md5 fingerpring> -- [email protected]

Note: In Ubuntu, you can use apt package: apt-get install ssh-agent-filter.

Updated on 2023-03-22: ssh-agent-filter is available on mac with Homebrew https://github.com/everpeace/homebrew-ssh-agent-filter

brew tap everpeace/ssh-agent-filter
brew install ssh-agent-filter

[ink-splatters]

I opened similar issue: https://github.com/maxgoedjen/secretive/issues/460 and found the solution which works for me:

I'll specify it here as well, just in case.

% cat ~/.ssh/config 
Host *
        IdentityAgent ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh
        IdentityFile ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/cedc8d35d8e6a2bcf6386415ee8a5acc.pub


Host myorg.github.com
        HostName github.com
        IdentitiesOnly yes
        IdentityAgent ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh
        IdentityFile ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys/970808bd9e0cb7ecdcdffb791cf6624e.pub

for this to work, make sure ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys exists (which is not the case now due to: https://github.com/maxgoedjen/secretive/issues/440), e.g.:

% mkdir -p ~/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/PublicKeys
% pgrep -i secretive | xargs kill -9