Feature request: Make the SSH agent work with any vault

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

+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 :)

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.

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.

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

Thanks. Still interested, will join that channel.

@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/