SSH Feature questions

@skrtks @aurimasniekis @negnetsolutions We've recently made some improvements in this area, especially around those consecutive prompts piling up. Could you see if it got any better now?

@nikolamilekic I agree and we're aware of this. It's a requirement we're looking to remove soon. The reason why it's there is because we need to build an opt-in mechanism to use those keys.

Like @skrtks mentioned, I use nvim inside of tmux and have plenty of different git integrations that are always checking the status of remote git repos. I get 1-2 ssh key requests each time I open a new shell / vim session. Or opening a transmit session over sftp (which by default opens multiple remote server connections) often ends up with 4-8 requests to unlock.

I realized that my git integrations are not the most optimized. But, an "always allow for process" would be a very nice addition.

In fact, using 1P to unlock my primary ssh identity is essentially useless for me right now as I'm constantly interrupted by authentication requests. For now, I went back to using local key files.... :(

Like @skrtks mentioned JetBrains IDE's constantly fetches git data, which causes 1password ask for allowance, which if u have for e.g. 5-6 IDE opened quite annoying, I would love if there would be option like with macOS keychain Always Allow or something similar

I've transferred some of my SSH keys I use frequently to 1P to do some testing, and I'm really enjoying the experience so far! However, what I don't like is that keys are locked quite fast after use. For example, Intellij frequently fetches in the background, and every time this happens I have to grant access to the key again.

It would be great if 1P would remember my choice as long as my vault is unlocked. Or even better, just remember which apps have access to a key, and don't ask me anything as long as my vault is unlocked.

What are the plans regarding this?

floris_1P I read those requirements and I understood the private vault one to mean any vault that is not shared. As I'm not the only one to come to that (wrong) conclusion I feel you need to explain it better. Instead of saying private vault how about saying "the account's default vault" (if that is indeed the case)?

Why is this requirement there to begin with? It's not intuitive (or we wouldn't be here), and it forces users to change their workflows to suit the software...

@nikolamilekic That's not a bug. We've listed the SSH key requirements for the SSH agent here: https://developer.1password.com/docs/ssh/agent#eligible-keys

Anything you feel that's missing there to prevent others running into the same issue?

rctneil Yes, you're right that the or part is a bit confusing, because not every SSH client supports IdentityAgent. So we just released a brand new page to list which SSH clients support which configuration options: https://developer.1password.com/docs/ssh/agent/compatibility

It says there that ssh-add does not support IdentityAgent, for example.

We're also linking to this page from the get started guide.

I just wasted a lot of time trying to figure out why SSH wasn't working for me. Same issue as @kevinneufeld: only "Personal" (or default) vault works. The other private vaults DO NOT. Is this a bug or a poorly documented feature?

Enceladus Many many thanks for your explanation.

When I get back on my personal machine I will reread your post and try it all out!

Thanks!

I was having trouble with this too and got it working. I had originally created an ssh key in my "Work" vault (not shared with anyone, but I don't think it counts as private), and was bemused as to why ssh -v was failing and claiming the agent had no identities.

Moving the key to the Personal vault fixed it. I can ssh hostname and 1Password prompts me for permission to connect, easy peasy.

rctneil IdentityAgent is a way to override the SSH_AUTH_SOCK variable. It lets you instruct SSH to use a different ssh-agent for particular hosts, while SSH_AUTH_SOCK is the default. If 1Password is the only ssh-agent you're running, you can export SSH_AUTH_SOCK=<that long path> as suggested and that should work fine. No need to set IdentityAgent at all.

In my case I'm already running a different agent on SSH_AUTH_SOCK. So I set up my ~/.ssh/config file like this for 1PW:

```config
Host somethingtouse1passwordfor
HostName 123.456.78.910
User username
Port 42
IdentityAgent ~/.1password/agent.sock // symlink to the full socket path

Host *
IdentityFile ~/.ssh/my-normal-id
AddKeysToAgent yes
``
Note that in this case,ssh-add -lonly shows the keys in my default agent, NOT what's in the 1PW agent. The reason for this is thatssh-addlooks atSSH_AUTH_SOCK` to get the socket through which to communicate with an agent. If I want to see what's saved in the 1PW agent, I need to change the environment variable. I can do this temporarily for my current shell session like so:


SSH_AUTH_SOCK=~/Library/Group\ Containers/2BUA8C4S2C.com.1password/t/agent.sock

And then ssh-add -l will report the key(s) from 1PW.

The documentation kind of assumes someone already knows how this works, which is probably a mistake given how arcane SSH can be and how minimal the usual instructions are that people get from github, web hosts, etc. If anyone wants to read a genuinely good explanation of what's going on, https://yayimorphology.org/ssh-identities-made-easy.html saved me a lot of headaches.