Feature request: Make the SSH agent work with any vault

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.