Ability to specify which key to use (otherwise: Too many authentication failures)

Ok, so color me confused. What's the purpose of putting keys into 1Password and using the ssh-agent if I still have to individually configure each host in ~/.ssh/config?

Shouldn't the ssh-agent intercept the requested host, look up the corresponding key and make the connection without my having to store my public key still in my file system and pointing to it in my config? I thought the purpose of this exercise was to make the management and storage of keys easier.

Here's my config (obfuscated):

Host hostshortname hostaltname
Hostname hostshortname.mydomain.com
IdentityFile /my/path/to/my/keystore/mailto:loginaccount@hostnamekeyfile.pub

Wouldn't it be advantageous if 1Password provided an option to store the account(s)/logins the key name applies to so all I need worry about is indicating in the 1Password key item, the login is identified so it can make the match and do its thing?

I definitely don't want to poopoo this capability. I'm tickled to death I can keep my private keys in 1Password. I just think additional features would be great too.

I'm having the same issue with Too many authentication failures. I lost plenty of time moving everything to 1password only to discover that I had to revert what I did... This is not serious really, you could have pointed out that issue when you release your article on the subject =/

This is unfortunately how the SSH agent protocol works. You don't 'add keys for host XYZ', you just 'add keys' and your SSH client will try them all one by one. The SSH config is there if you want to do explicit matching, but that's only needed if you have more than 6 different keys or if you want to keep things strictly separated.

We do see that there are a few alleys open for us to improve the experience in area, which we are currently investigating. So stay tuned!

And @Ekami67, could you describe what there is to revert or why that's needed?

This page is vital. https://developer.1password.com/docs/ssh/agent/advanced/#ssh-server-six-key-limit I wonder if the agent could be configured to output instructions to the terminal when the "Too many authentication failures" occurs. Or perhaps 1password could display a dialog.

Unfortunately, we don't have any control over what SSH clients log. What we are looking into is to see what we can do to more proactively warn about this.

Is there no way in 1password to get the same functionality we have with websites but with hostnames for ssh keys? Even if the first time it encounters a host it asks which to use like you do in the mobile apps to attach an app id to a login?

@Gudlyf We've added support to the agent for legacy ssh-rsa connections. Available in the latest 1Password beta!

@digitalfiz This would diverge from typical SSH workflows (as hosts are not part of the SSH agent protocol), but it is something we're looking into.

Struggling with this.

* Generated a key pair manually (as I need to use on remote dev server as well as locally, so I need access to the cert password)
* Created 1p SSH key and imported the key (passing in the saved password as part of import)
* Added key to remote and tested working by modifying my config file to specify the key to use. Successfully logged in from OSX Terminal application (i.e. without using 1password, to confirm that the cert and password works for login to this server)
* Remove ssh config setting, so login should be via 1password. Tried ssh with 1password: Too many authentication failures. This is probably because I have too many certs in 1password
* Tried shifting most of my ssh keys out of the 1password private container so I only had 6 certs. Tried ssh login: Too many authentication failures.
* Tried instructions above on this page. Exported the public key from 1password and specified it in the config file according to instructions above. "mailto:root@domain.domain.com: Permission denied (publickey)."
* Maybe it is related to permissions, ensured permissions on the exported file are secure, tried again, same result

Host mydomain.domain.com
User root
IdentityFile /Users/rodney/.ssh/id_ed25519.pub
IdentitiesOnly yes

At this point I give up.

Can someone provide step by step (bullet proof) instructions on how to get this working please.

Rod

@rodneyt If you run ssh -v mydomain.domain.com, it should print out which keys it tries in which order. Can you see if the public key you've downloaded and added to your SSH config is listed in the -v output?

I love this feature... however i'm finding this "Too many authentication failures" issue really annoying. I accept the workarounds above, but having to add SSH config for every host I want to connect to really ruins the user experience for me.

To state the obvious - One of the great benefits of storing SSH keys in my vault is that I can confidently have one "primary" SSH key and use it's public key everywhere; resting with the knowledge that the private key has never left 1Password's vault.

Before this feature, I would have a bunch of different keys for different hosts (with the aim of limiting the scope of any breach of a particular private key). The downside of this was i'd need to configure or specify which key to use for each host I connect to. Maintaining a long ssh_config file is pretty inconvenient, so I was excited at the prospect of not needing to do this anymore. Yet here I am, updating my ssh_config on a daily basis!

@floris_1P - These may not be technically possible but see 2 potential solutions / ideas which I would love to see implemented:

• The ability to select a "primary" SSH key under the 1Password SSH agent settings, which is the first key offered up by the 1Password SSH agent. (Or even better.. a drag-drop interface to set the order of which SSH keys in my vault are offered). This would allow me to set my "primary" key at the top of the list.

or..

• The ability to toggle on/off a "Use with the 1Password SSH Agent" switch on SSH key items in my vault. For context; I have a bunch of old keys in my vault which I (probably) will never use again; but I want to keep them somewhere safe. This would allow me to do that without hitting this issue.

I look forward to seeing what comes in future releases!