Feature request: Make the SSH agent work with any vault

ismael092

Currently, the 1Password SSH agent only works with keys in the Personal or Private vaults. It would be great to expand this feature to work for shared vaults. That would be very helpful for development teams, particularly, to prevent everyone in the team from adding the private keys to their machines which is less safe and makes rotation troublesome.

---

1Password Version: 1Password 8.7.0
Extension Version: Not Provided
OS Version: MacOS 12.3

floris_1P

We're working on a way to opt in to using keys from other vaults. If we'd offer such a mechanism, would you prefer an opt in per vault or per individual key?

BobW

I'd really like this, too. I finally got a chance to check out the new ssh functionality and ended up bailing out when I ran into this limitation. In all of my accounts -- a mix of multiple family accounts and a business account -- we don't use the personal vaults at all. On the family side, my spouse and I need access to each other's and our kids' and elderly relatives' complete collections, while at work, we want to be able to access a former employee's items without going through the fuss of doing an email-based password reset. (For more about this, see this discussion, this one, and this one.) Thus, this feature is basically unusable to me right now. I'm playing around with somehow hooking things up with the op command, but I'm not sure it's worth the effort.

As for the opt-in, I'd definitely prefer per-key. Especially in a team setting, I can envision a number of scenarios where one has a bunch of shared keys in various vaults, most/all of which can't be relocated to other vaults, so having to opt-in all those vaults would mean potentially checking many more keys. That often would force you to go the trouble of downloading the public keys and linking them up in the config file, or at least living with a slower auth process.

That said, it'd be nice to also get vault-level opt-in at some later date :-).

BobW

Any updates on this? Such as whether it's on the near-term radar yet, or if it's still at the discussion phase?

I love the feature, but it's totally useless to me being tied to the Private/Personal vault. I also have a project at work for the devops team to distribute managed keys to the engineers via 1P like we do for some passwords, but it's on hold because of this limitation.

MartonS1P

We're working on it, but cannot share any specifics related to the timeline of this project.

zfreeds

@floris_1P , to answer your question I would like to opt-in per key. Maybe with a boolean "Activate on this computer". I would also like the ability to change the name the key downloads with. For example, I use id_work.pub before manually moving it to the .ssh folder. Feel free to reach out if you want more information on how I use it.

1Jeff

+1 from me on this. From the perspective of product positioning this probably starts to get into whether the Connect server or SSH Agent should be used when you discuss internally, but sometimes you may want to share keys amongst humans for human access (for example, human-centric BCDR needs), while leaving other keys to be used in service automations (for example, everyday automation). It should absolutely be supported to use a key from any vault and left to the customer to configure that usability as desired.

@floris_1P I would like both kinds of granularity. I see this as a server-side policy like the permissions system, and an optional item-level flag so, for example, I could have a vault called "Shared Break Glass SSH Keys" which is "vault-level-enabled" for any SSH Key to be used, but if I want to have, say, an SSH Key called "Root Key - Seriously Only Ever Use In An Absolute Emergency," I could have that one explicitly configured as exempt unless I go change that at the item-level. This preference could be stored in the vault metadata for the vault-level setting, and the item itself for the "item overrides". The precedence of configuration could be such that an "allow" at the vault level can be constrained by an "item-level override", and a "deny" at the vault level could disallow any key being used regardless of it's "item override". I hope that makes sense :)

MartonS1P

Thanks for the input @zfreeds and @1Jeff!

BobW

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.

JustSomeNobody

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.

TinTheParkin

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.

nowayswiveltyro

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.

wojo

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

gparera

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

Jack.P_1P

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

Raggaer

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

Jack.P_1P

Hey @Raggaer:

Thanks for your feedback! 🙂

Jack

clowa

+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 !!!

Jack.P_1P

Hi @clowa:

Thanks for sharing, and glad to hear you like 1Password SSH Agent so far! 🙂

Jack

lantrix

Same here. The SSH agent has been a game changer, especially for my work account. But having to duplicate the teams SSH key into private makes it onerous. Great to see you're working on it.

floris_1P

@ismael092 @BobW @zfreeds @1Jeff @JustSomeNobody @TinTheParkin @nowayswiveltyro @wojo @gparera @Raggaer @clowa @lantrix

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 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.

gparera

@floris_1P, great news. Glad to hear that.

lantrix

Thanks. Still interested, will join that channel.

Johana24

Thanks, I am really interested, any update?

chris.db_1p

Hi @Johana24, thanks for your interest! You can join the #ssh-agent-config channel in our Slack workspace to see the latest updates and instructions on how to try out the feature in the Nightly release. We'd love to hear your feedback!

clowa

Hi @floris_1P, so sorry, totally misted your great news. Unfortunately I don't use slack, any other option to still get the instructions on how to use this feature? Or is this the price I have to pay :D

matteocontrini

@clowa the feature was released to stable with version 8.10.8 (released yesterday) and is documented here: https://developer.1password.com/docs/ssh/agent/config/

ag_tommy

Thanks matteocontrini for that assist.