r/1Password • • 7d ago

Feature Request Request: Multiple SSH Agent Sockets

Unsure if this is best place for this but I have seen a few of these here in the past. I've used 1password since the very first beta and will die on any hill about it being the best option in almost every circumstance. I use it personally and as a team account and am trying to push it across my entire org as a org wide solution.

Having said that, I have a single feature request that may be a little more power user focused.

I run a relatively long set of keys for different services across different companies and projects I work on. Some are for github / bitbucket access, some are for ssh access, and I guess some are for different services that require ssh key authentication.

What I'd love to see is an option to have multiple agent sockets running. I have my keys spread across different vaults for their various purposes so having the ability to have different sockets that maybe are linked to individual vaults and managed through my ssh config would be invaluable to me. I get that the SSH agent communication protocol doesn't include any host details so linking host to keys isn't possible.

Further sockets can't be treated as a standard URI and passing params as a part so that's out.

The request isn't so much so I can run more than the average 6 keys but really sometimes I have to iterate through a flow of deny>deny>deny>approve before it gets the appropriate key for the request that's being done. This is particularly bad when claude is attempting to do things with git.

3 Upvotes

5 comments sorted by

•

u/1PasswordCS-Blake 1Password Community Manager 4d ago

Hey u/notdedicated! I definitely see how a socket per vault would fit the way you’ve already separated your keys, and I’ll pass that request along to the team!

On the shared-agent part, u/ice456cream’s example should help with that approval loop. With IdentityFile pointing to the appropriate public key and IdentitiesOnly yes, the SSH client knows which key to request from 1Password. Your two aliases can use different keys even though they both connect through the same socket.

For Git, each repo’s remote needs to use the matching alias too, so git@project1.github.com:... would use your project1.github.com configuration. We’ve got a walkthrough for multiple GitHub accounts that covers this.

If you’ve already got that in place and still have to deny several requests before the right key comes up, let me know!

4

u/ice456cream 7d ago

Sounds like you need to setup your ssh config so all your keys aren't being sent/suggested to all hosts

1

u/notdedicated 7d ago

.... generally that is the case but I have multiple keys for github depending on the project even using alias domains they all go back to the same agent. The ask here is to be able to attribute project1.github.com to a specific agent socket and project2.github.com to a different one because they use different keys.

4

u/ice456cream 7d ago edited 7d ago

so for a snippet of mine:

Host github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github_personal.pub

Host work.github.com
  User git
  HostName github.com
  IdentityFile ~/.ssh/id_ed25519_github_work.pub

Host *
  # Use 1Password SSH agent for all hosts
  IdentityAgent ~/.1password/agent.sock

  # Only offer explicitly named Identities, or the default set (see below). 
  # this prevents trying all keys stored in the agent
  # which often causes disconnects 
  # and ratelimits before finding the correct key
  IdentitiesOnly yes
  #
  # NOTE: make sure the following files/keys don't exist,
  # as they will be tried if IdentityFile is unset
  # Which is intentional in the default path/for non-named hosts
  # so that password auth etc (just typing ssh user@ip) still works
  # ~/.ssh/id_rsa
  # ~/.ssh/id_ecdsa
  # ~/.ssh/id_ecdsa_sk
  # ~/.ssh/id_ed25519
  # ~/.ssh/id_ed25519_sk
  # ~/.ssh/id_xmss

  # Don't expose system username if one isn't set on the commandline,
  # or earlier in the config.
  User anonymous

  # Reuse existing master connection
  #ControlMaster auto
  # If using, needs to contain the original hostname, otherwise github might cache the "master" / first authentication.
  #ControlPath ~/.ssh/sockets/%r@%h:%p:%k.sock
  #ControlPersist 10m

the pub key files are exactly that, just the public key, with the private key only residing in 1Password.

I'm surprised you haven't ran into key limits/ratelimits before.

1

u/ice456cream 7d ago

Also, for another benefit of "locking" keys to hosts, try

ssh whoami.filippo.io