Feature request: Make the SSH agent work with any vault

+1 Would really looking forward to see this feature implemented. I Have spend like days figuring out why some ssh keys didn't work with the 1password agent till checked if they are in different vaults.

The 1Password SSH Agent is such a great feature to securely sync ssh key between devices and makes it so easy to use different keys per server. Please make this feature even better !!!

Hey @Raggaer:

Thanks for your feedback! 🙂

Jack

Big +1. It would be amazing to have this.

Hi @gparera / wojo:

Thanks for your feedback! While I can't promise any timelines, as my colleague Marton mentioned, we are working on it. :)

Jack

+1. It's almost mandatory on an enterprise environment.

+1 on this for many of the same reasons above!

I am also very keen for this to be implemented!

If this were implemented then I would likely have a vault dedicated to ssh keys I'm comfortable with using like this, so for me, I would prefer an opt in per vault.

Hey folks!

This is a massive +1 for me too. Would like to be able to select a vault to utilise SSH keys. I plan to have a separate vault specifically for keys.

I am a +1 for this as well.

The ability to whitelist which keys are exposed would be delightful but I can make due with just a simple selection tool that allows me to opt selected vault(s) in to the ssh agent.

I have almost nothing in the default/personal vault and keep ssh keys and the like in various vaults for quick "travel mode" selection.

Agreed with @1Jeff that both levels would be very useful.

That said, I'd think that any item-level control in a shared vault should probably be user-specific. Consider that the set of frequently- or infrequently-used items within a team vault can vary quite a bit across a team depending on each person's specific role on the team and their daily tasks. Even going to the machine level would be handy -- consider the worker who does most of their heavy work on a desktop at work but who does some lighter stuff on a laptop in the evenings at home.

Have you guys considered using multiple socket files to map SSH config entries to keys? I know 1P supports the IdentityFile approach, but that's rather janky:

• It requires exporting public keys. This rather defeats part of the reason for using 1P as an agent, and is downright silly for keys generated inside 1P.

• It defines a whole new set of clients that don't work with 1P because they don't understand public keys in that context.

But if each key could have its own socket (or a socket lookalike, like maybe a bind mount), then both of those are avoided: the user doesn't have to mess with exporting and managing key files, and you're not creating a whole new group of incompatible clients. Additionally, you completely avoid the six-key problem, and the UI changes related to item-/user-/machine-specific functionality shift from being a necessity to being a nicety, as the GUI becomes an alternative, shortcut UX instead of the only UX.

You could even extend the approach to offer vault-level sockets, and possibly collection-level, too (though the latter would reintroduce the six-key problem, albeit in a way less likely to be hit). Altogether, this would give us a huge level of flexibility in terms of security scopes that would let us do about anything we could need with minimal, sensible configuration.