Getting SSH key support to work (macOS, version 8.6.0 beta)
I was interested to read the Blog post about the new SSH agent/key support, but, for the life of me, am apparently missing something obvious in getting it to actually work.
I have read through the documentation, and have extensive familiarity with setting up SSH keys, using agents, and so on, but, no joy.
The documentation specifically mentions setting up your new SSH keys in "your Private vault"; I'm not sure if the use of the word Private is crucial here, but, assuming a level of pedantry, I created a new Vault called "Private". I then created a new key.
I've enabled the SSH agent in the Developer preferences of 1P8, and modified my .ssh/config file for a specific host to use the socket for the IdentityAgent. I've tried both the full "Group Containers" path, as per the snippet in the Preferences, as well as the symlinked socket in .1password.
I have rebooted multiple times, and ensured 1P7 was removed from this machine (M1 MBP, new). 1P8 starts at login, and I open/start it before testing SSH.
I've also tried exporting the SSH_AUTH_SOCK explicitly, and checking with ssh-add -l.
No matter what I do, no identities are available in the agent.
And, predictably, whenever I try to log in to the defined host, it fails, and falls back to Password.
I also tried defining the global "Host *" option with the socket's location, still didn't work.
Even tried specifying IdentitiesOnly for the host I'm testing with...nope.
Must be missing something so obvious that I just can't see it...any hints appreciated.
1Password Version: 8.6.0
Extension Version: Not Provided
OS Version: Not Provided
Comments
-
Seems I'm having a similar issue to you. Sounds like a bug in the software.
Hopefully we get a response in the community as support are not coming back to me.
0 -
Hi, I was having similar issues and the problem was in the vault choice. Only keys I've got in my "first" vault show up, others are ignored. I had named the vault "Personal" and I don't understand the "Private" reference either. Therefore, my advice to you would be to try and put 1 SSH key into each vault and see if one of them shows up in ssh-add -l.
0 -
Every 1Password account comes with a vault called
Private, where you can store the items that you want to keep for yourself. So also if you have a work account, you still get a Private vault where you can keep your work-related but still private items, like the login to your work email.ssh-add -lshould list every SSH key item from all Private vaults on any account.If you log in to 1password.com, you should see your Private vault listed there:
0 -
I have the same problem. I set things up according to the docs, configured $SSH_AUTH_SOCK in my shell profile and the agent in ~/.ssh/config, but I still see from ssh-add -l:
The agent has no identities.That Private vault info is also incorrect. It may be that new accounts all have a Private vault (no idea), but for my account that was in the first launch of 1Password Families, the "Private" vault doesn't exist and never has. I have Personal, Shared, and a couple other vaults that we've added on. My SSH key is in a vault I created for work purposes. I'm running the 1Password 8 beta (latest) on macOS 12.3.
I checked the 1PW logs and see the following:
rg ssh ~/Library/Group\ Containers/2BUA8C4S2C.com.1password/Library/Application\ Support/1Password/Data/logs/1Password_rCURRENT.log
13:ERROR 2022-03-17T14:20:36.727 ThreadId(12) [1P:ssh/op-ssh-config/src/lib.rs:128] Could not open ssh config file in ~/.ssh/config
37:INFO 2022-03-17T14:20:36.750 tokio-runtime-worker(ThreadId(9)) [1P:ssh/op-agent-controller/src/desktop.rs:285] SSH Agent has started.My SSH config is set up correctly:
ls -al ~/.ssh/config
-rw-r--r-- 1 staff 368 Mar 17 14:14 /Users//.ssh/configHost *
IgnoreUnknown AddKeysToAgent,UseKeychain
UseKeychain yes
AddKeysToAgent yes
IdentitiesOnly yes
IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"0 -
Sorry about the confusion! The
Privatevault can also be calledPersonal, depending on which 1Password plan you're on:
The docs are not clear about this, we'll make sure that gets fixed. Could you guys try moving the keys to the
Personalvault?0 -
Thanks for the clarification. I did move the key to my Personal vault, and now it shows up in the agent, verified with
ssh-add -l. For some reason, though, I haven't been able to use it in ssh authentication. For example, I added the public key to my GitHub account, and then ran:❯ ssh -T git@github.com git@github.com: Permission denied (publickey).
0 -
That was it, @floris_1P - I was able to get it to work as advertised by moving the keys to my Personal vault.
It might be nice if the vault name for this feature was configurable. I can think of a few use cases where this would be helpful, rather than hard coding it based upon 1Password plan...
0 -
@doetraar Great! We've updated our docs now to reflect this better. And yes, more flexibility in this area is coming! If we would offer this, would you prefer an opt in per vault or per individual key?
@speedtrial113 Could you share your SSH config and
ssh -vT git@github.comoutput?0 -
@floris_1P There are merits to both approaches. Per key would allow the most flexibility for those of us who like to keep a smaller number of vaults, but, if one has organised a larger number of vaults, then chances are per-vault opt-in for the 1P SSH agent functionality would be ideal. For me, personally, I can live with either. I'm still working out how best to use the functionality as I have many dozens of keys, and have avoided the "IdentitiesOnly/IdentifyFile" approach unless really necessary -- but the more keys in the agent, the more likely the limit-of-six for the sshd side of things becomes problematic.
For me, personally, I'd prefer the per-key opt-in, as it would allow the most granularity, and still afford the ability to group keys in vaults if they have something in common in my data organisation.
0 -
I've been frustrated for days over this. I had my personal GitHub key in my personal vault and my work GitHub and GitLab keys in a secondary vault of the company name. I've now moved them all the my personal vault and all three are working.
Why does the integration need to be limited to a single vault? I'm not using a company 1Password account, just creating separate vaults for organization and easier clean up if I switch companies.
0 -
I just got this working as well but don't like the fact that I must store my ssh keys (work) in my personal vault. I'd much prefer to designate a 'SSH_KEYS' vault and keep them together. +1 for having the ability to identify or opt-in for other vaults. Optimally, identical to Personal (my plan) but with a different name. Or, add an option for each vault created to toggle Personal/Private on/off. If the toggle is enabled, simply consider it part of Personal if it makes things easier.
0 -
I just got this working as well but don't like the fact that I must store my ssh keys (work) in my personal vault. I'd much prefer to designate a 'SSH_KEYS' vault and keep them together. +1 for having the ability to identify or opt-in for other vaults. Optimally, identical to Personal (my plan) but with a different name. Or, add an option for each vault created to toggle Personal/Private on/off. If the toggle is enabled, simply consider it part of Personal if it makes things easier.
0 -
Hi @floris_1P (or anyone else, for that matter). Instead of opening another issue (let me know if that's preferable to me continuing here). I have this all enabled in 1Password, and have tried following everything in this thread, but I am not certain how to confirm (if I have 2 keys, for GitLab, for example) if it's working. Is there a way to check? Thanks!
0 -
@doetraar @mattcooper @mxmxcz @speedtrial113 @adenix @zaxaz
I wanted to let you know that we're currently working on a solution that allows for the following:
- Enable keys from other vaults than the Private/Personal vault.
- Create isolated setups with certain keys offered on a separate socket.
- Control the order in which keys are offered to SSH servers.
It would be great to get your feedback on our proposal, if you're (still) interested. You can do so by joining the
#ssh-agent-configchannel in our Slack workspace.0
