Feature request: Make the SSH agent work with any vault

Community Member
edited March 31 in SSH

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_1Pfloris_1P

    Team Member

    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?

  • BobWBobW Junior Member
    Community Member
    edited April 20

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

  • BobWBobW Junior Member
    Community Member

    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.

  • MartonS1PMartonS1P

    Team Member

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

  • zfreedszfreeds
    Community Member
    edited August 3

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

  • 1Jeff1Jeff Members
    Community Member

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

  • MartonS1PMartonS1P

    Team Member

    Thanks for the input @zfreeds and @1Jeff!

  • BobWBobW Junior Member
    Community Member
    edited August 16

    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.

  • JustSomeNobodyJustSomeNobody
    Community Member

    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.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file