Suggestion: Allow SSH Keys in any vault, choose which ones to export

Yes, we will eventually lift this requirement, but we'll need to have an opt-in mechanism for that. Would you prefer an opt in per vault or per key?

Hi, currently I have 1 key for personal use, and another key for work stuff. So I would be fine with opt-in per vault.

But considering there might be someone with much more keys, I think it would be better if 1Password allows opt-in per per key.

I would purpose a different solution.

I would like to see the agent.sock be available per vault and per collection


Host *
IdentityAgent "~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-vault-personal.sock"
Host *.work.com
IdentityAgent "~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-collection-work.sock"
Host *.foo.org
IdentityAgent "~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-vault-foo.sock"


I would not want a separate socket for each group.

I have one key in my Personal vault for my Family account and three keys in my work account Private vault. All of them present correctly.

@kormoc That's an interesting angle that we haven't considered yet! But I do agree with @austin, having separate sockets per vault is maybe a bit much. It's not what the IdentityAgent value is meant for. Also, doing that will make dealing with clients that only support SSH_AUTH_SOCK more painful. What would you consider to be the benefits of such an approach over IdentityFile / IdentitiesOnly?

Supporting multiple, isolated agents is a requirement for me. Forwarded agents are open to everyone that has access to the agent socket on the remote hosts.

If I have in my agent keys for foo.com and bar.com and I ssh to baz.bar.com with agent forwarding on, any one with root on baz.bar.com would be able to hijack my agent and ssh to hosts in foo.com.

I handle this by having multiple agents and ensuring keys are only loaded in domain specific agents and thus only forward keys that apply to that company's hosts.

1Password's implementation of ssh agents is limited to a single agent that has all the keys loaded in it. IdentityFile/IdentitiesOnly only ensures that the right key is used for auth, but nothing on which keys are actually able to be used on the remote host.

Per vault would be nice, but I could setup a collection of only one vault if they were exposed only via the collection level.

And SSH_AUTH_SOCK would still work just fine, you'd be able to do SSH_AUTH_SOCK="~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-collection-work.sock" /usr/bin/foobar just fine.

I'd be in favor of opt-in per vault. I'd be fine with configuring my work machine for example to use my work vault for SSH and my personal vault on my personal machine. That's basically how I did it pre-1Password for setting up the SSH keys I used.

I'm fairly new to your product, the main reason I changed lastpass for yours is the ssh feature - Kudos!!

I believe being able to use multiple different vaults is a must feature, I'll be introducing 1pass to my company (We're mainly if not only engineers), ideally I'd like to be able to split teams into groups of devs, but most of them will need access to multiple different projects, but some of them won't.

Essentially currently you can't have keys shared with "family" or your team.

Being able to roll out such a feature makes a huge diff.

Love the idea of a per-vault socket file, this helps solve the situation with both work and personal keys in my situation as well.

@Goddesen @zhaoweny @kormoc @ascarter @Aurond

I wanted to let you know that we're currently working on a solution that allows for the following:
- Enable keys from other vaults than the Private/Personal vault.
- Create isolated setups with certain keys offered on a separate socket.
- Control the order in which keys are offered to SSH servers.

It would be great to get your feedback on our proposal, if you're (still) interested. You can do so by joining the #ssh-agent-config channel in our Slack workspace.