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

Yes, you can specify the key to use via IdentityFile in the .ssh/config file. You can view the keys by running


SSH_AUTH_SOCK="$(readlink -f ~/Library/Group\ Containers/*.com.1password/t/agent.sock)" ssh-add -l


You'll see an line per key in the form of


KEY_SIZE SHA256:KEY_HASH FILE_NAME (KEY_TYPE)


Set your IdentityFile equal to the FILE_NAME and it will use that key.

Set your IdentityFile equal to the FILE_NAME and it will use that key.

Hm, I see FILE_NAME is just a single word (like foo1) but adding that as IdentityFile foo1 seems to look for an actual file. Is that the correct way to define it, or do I need a path?

See this page on how to deal with the Too many authentication failures error. You'll have to download the public key file and use that as IdentityFile. ssh-add -l only shows the key item name.

AW, that stinks, but I suppose it makes sense. I moved all of my SSH keys into 1Password, hoping I would no longer have my keys exposed on the filesystem. I guess I need to just go back to that. I hope 1Password figures out another solution some day!

@floris_1P -- From the docs you linked, it says to export the public key, not the private key. That doesn't make sense -- shouldn't it be the private key?

@Gudlyf No, it's really the public key! That would otherwise defeat the purpose of having this built-in SSH agent 😅.

IdentityFile is indeed most famous for its use with private keys, but you can also use with public keys, so that the private keys never have to leave the SSH agent.

@floris_1P Yeah I figured that was the point but doing that doesn't seem to work.

sign_and_send_pubkey: signing failed for RSA "/Users/username/.ssh/id_rsa.pub" from agent: agent refused operation
user@x.x.x.x: Permission denied (publickey).

Changing to the private key file works.

Do you see anything appear in the 1Password logs when you run the SSH command? On macOS: ~/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/logs/1Password_rCURRENT.log

@floris_1P Ah, thanks for pointing me to that. Looks like it's an older SHA-1 key we'll need to update.

It's not an issue with the key itself, but rather the communication mechanism between the SSH server and the SSH client when using RSA keys. If the server supports a more modern RSA algorithm (like rsa-sha2-256), you can add this snippet to your SSH config to opt out of the legacy ssh-rsa algorithm.


HostkeyAlgorithms -ssh-rsa
PubkeyAcceptedAlgorithms -ssh-rsa


However, some servers and some clients only support ssh-rsa for RSA keys. In some cases, simply switching to an Ed25519 key is a feasible workaround. But we're also working on adding better legacy support to the SSH agent, we'll post an update in this thread when that's released.