Feature Request: SSH Agent improvements

rellek
rellek
Community Member
edited January 8 in SSH

Hi,

I was a little confused about the SSH Agent and the limit to 6 keys. So I submitted a support request #202069 which led me to here to lay out my ideas on how to vastly improve SSH workflows with 1Password.

It's gonna be quite some text, so please bear with me.

To make one thing crystal clear: When it works, it's awesome!

However, when it doesn't, it gets confusing. Let me explain.

I am using a password manager to have as little to do as possible with login credentials of any sort. And it works ... "well enough" as long as you have less than 6 certificates to manage.
But then you will run into this SSH limit because 1Password "bruteforces" all certificates until one works. The workaround, which is documented in the manual, is to export the public key and edit ~/.ssh/config and "register" the hosts, with the public key, and tell SSH to only use keys.

And I disagree with this workflow. Because I am using a password manager so I #don't# have to handle credentials.

So I would suggest that 1Password generates the config file (and handles everything that's attached to that) for me.

My idea would be: When creating or editing an SSH key, give me the opportunity to add context for 1Password (and also for me! Like I know where those keys are used "today", but will I in 5 years as well? I mean sure, give them meaningful names, or add notes - but honestly, is the majority of users that organized? I certainly would not be). Give me a field what it's used for - say a hostname. So I can say, THIS certificate is for srv1.example.com (bonus points if I could also specify the port). And maybe a "nickname", so I don't have to enter
$ ssh username@srv.example.com
but
$ ssh username@dev

Which literally is just one more name in the "Host" line of ~/.ssh/config.

And when you are at it, also the desired username. That way, all I have to enter is
$ ssh dev

And it connects to srv.example.com - at the desired port - with "username" as the user.

1Password would automatically export the public key and generate this file (or, WordPress-style, add its stuff to it if there is already non-conflicting configuration), and keep everything in sync.

Because THAT is the point of my idea. Keeping the keys in sync.

That way, you could also solve the issue you stated in the docs of having a private and a company GitHub account with a nice UI. Make 2 keys, host is github.com, nickname is "personalgit" for one and "workgit" for the other - and boom, 1Password does it all for you.

Well and if you don't fill out the metas, everything remains as it is now. For example when you need a key pair for something else that won't use SSH. (Not that I had an example for this tho, but I'm sure there are use-cases where a key pair is needed)

(Also, I'd like an UI for which vaults to consider for SSH keys, but that's another topic)

YES. I #am# aware that this is mostly a one-time configuration thing. But, that one time sucks in my opinion, especially if you are just getting into this, be it because you just started using keys or because you migrate your keys to 1Password... However, if you use multiple computers - say an iMac on your desk and a MacBook on the go, it sure would be nice to have the peace of mind that 1Password has you covered, no matter what.

--

Sorry for the wall of text. But I think that would be really useful improvements to the SSH agent.

If you made it to here, thank you. And also thank you for at least considering it :)

1Password Version: 8.10.23
Extension Version: 2.19.0
OS Version: macOS 14.2.1
Browser: Chrome

Comments

  • Michael Mercurio
    Michael Mercurio
    Community Member

    One trick which might help with running into the 6 key limit issue (which is not a 1Password limitation, but something that SSH servers enforce): you can add configuration to your ~/.ssh/config to specify the key to use for a given user and host. This means only the key specified will be used (if accepted), thus avoiding trying multiple keys and running into the limit.

    I find it easiest to do this by storing the public keys in my ~/.ssh directory and reference those in my ~/.ssh/config file (e.g. ~/.ssh/id_ed25519.pub). This has the added benefit of security by not storing private key files on disk.

    I then set options such as IdentitiesOnly yes and IdentityFile ~/.ssh/id_ed25519.pub in my host settings in ~/.ssh/config. This ensures that 1Password tries the private key corresponding to ~/.ssh/id_ed25519.pub first, and if successful, no other keys need to be attempted.

  • rellek
    rellek
    Community Member

    Hi,

    yes, I did that. But I'd find it a lot more convenient if 1P could do this automatically because that would also sync to other machines then where 1P is running on.