Suggestion: Allow SSH Keys in any vault, choose which ones to export

Community Member
edited May 3 in SSH

I have typical (I guess) vaults for personal use and for work use - and extra vaults in linked accounts. All of these may contain SSH Keys that I may want to use.

  1. Needing to have SSH Keys in my personal vault is limiting. I don't want my work keys there. I want keys in other vaults to be visible in the agent.
  2. I might end up with a whole lot of keys being exported, conceivably triggering a too many authentication failures error. Choosing which keys to export might alleviate this - possibly connected to the new Collections feature?

1Password Version: 1Password for Mac 8.6.0
Extension Version: Not Provided
OS Version: macOS 12.2.1


  • floris_1Pfloris_1P

    Team Member

    Yes, we will eventually lift this requirement, but we'll need to have an opt-in mechanism for that. Would you prefer an opt in per vault or per key?

  • zhaowenyzhaoweny
    Community Member

    Hi, currently I have 1 key for personal use, and another key for work stuff. So I would be fine with opt-in per vault.

    But considering there might be someone with much more keys, I think it would be better if 1Password allows opt-in per per key.

  • kormockormoc
    Community Member

    I would purpose a different solution.

    I would like to see the agent.sock be available per vault and per collection

    Host *
        IdentityAgent "~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-vault-personal.sock"
    Host *
        IdentityAgent "~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-collection-work.sock"
    Host *
        IdentityAgent "~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-vault-foo.sock"
  • austinaustin Junior Member
    Community Member

    I would not want a separate socket for each group.

    I have one key in my Personal vault for my Family account and three keys in my work account Private vault. All of them present correctly.

  • floris_1Pfloris_1P

    Team Member

    @kormoc That's an interesting angle that we haven't considered yet! But I do agree with @austin, having separate sockets per vault is maybe a bit much. It's not what the IdentityAgent value is meant for. Also, doing that will make dealing with clients that only support SSH_AUTH_SOCK more painful. What would you consider to be the benefits of such an approach over IdentityFile / IdentitiesOnly?

  • kormockormoc
    Community Member

    Supporting multiple, isolated agents is a requirement for me. Forwarded agents are open to everyone that has access to the agent socket on the remote hosts.

    If I have in my agent keys for and and I ssh to with agent forwarding on, any one with root on would be able to hijack my agent and ssh to hosts in

    I handle this by having multiple agents and ensuring keys are only loaded in domain specific agents and thus only forward keys that apply to that company's hosts.

    1Password's implementation of ssh agents is limited to a single agent that has all the keys loaded in it. IdentityFile/IdentitiesOnly only ensures that the right key is used for auth, but nothing on which keys are actually able to be used on the remote host.

    Per vault would be nice, but I could setup a collection of only one vault if they were exposed only via the collection level.

    And SSH_AUTH_SOCK would still work just fine, you'd be able to do SSH_AUTH_SOCK="~/Library/Group Containers/XXXXXXXXXX.1password/t/agent-collection-work.sock" /usr/bin/foobar just fine.

  • ascarterascarter
    Community Member

    I'd be in favor of opt-in per vault. I'd be fine with configuring my work machine for example to use my work vault for SSH and my personal vault on my personal machine. That's basically how I did it pre-1Password for setting up the SSH keys I used.

  • AurondAurond
    Community Member

    I'm fairly new to your product, the main reason I changed lastpass for yours is the ssh feature - Kudos!!

    I believe being able to use multiple different vaults is a must feature, I'll be introducing 1pass to my company (We're mainly if not only engineers), ideally I'd like to be able to split teams into groups of devs, but most of them will need access to multiple different projects, but some of them won't.

    Essentially currently you can't have keys shared with "family" or your team.

    Being able to roll out such a feature makes a huge diff.

Leave a Comment

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