Feature request: Make the SSH agent work with any vault

Thanks for the input @zfreeds and @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 :)

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.

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

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.

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

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?