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

Gudlyf

I was perplexed as to why I could not SSH into a system earlier today. It looks like ssh is simply trying all of the keys in my vault, one after another, though never getting to the one it needs before the server fails with "Too many authentication failures":

debug2: pubkey_prepare: done
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: foo1 RSA SHA256:... agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: bar1 RSA SHA256:... agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: foo2 RSA SHA256:... agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: bar2 RSA SHA256:... agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: foo3 RSA SHA256:... agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: bar3 RSA SHA256:... agent
debug2: we sent a publickey packet, wait for reply
Received disconnect from x.x.x.x port 22:2: Too many authentication failures for username

Is there any way to support specifying the key to grab from the vault so that this does not happen?

---

1Password Version: 8.7.0
Extension Version: Not Provided
OS Version: macOS 12.3

billvortex

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.

Gudlyf

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?

floris_1P

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.

Gudlyf

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!

Gudlyf

@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?

floris_1P

@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.

Gudlyf

@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.

floris_1P

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

Gudlyf

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

floris_1P

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.

zaxaz

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/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.

Ekami67

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 =/

floris_1P

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?

rodneyt

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.

floris_1P

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.

digitalfiz

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?

floris_1P

@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.

rodneyt

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. "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

floris_1P

@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?

jontyb

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!

jody.h_1P

Hey @jontyb, just wanted to quickly follow up to say I love this line of thinking! We're actively looking at ways to improve the SSH Agent experience for those with a many SSH keys, so this feedback is excellent. I don't have a timeline I can share right now, but keep an eye out for improvements down the road!

yboulkaid

I came here to post exactly what @jontyb wrote above 👍
I started the year by creating smaller-scoped keys and immediately started running into the "too many authentication failures" issue. So consider this a +1 to the feature ideas above :)

Jack.P_1P

Thanks for sharing @yboulkaid! 🙂

As Jody mentioned, we're actively looking to make using 1Password SSH Agent better for those with many keys, so keep an eye out!

Jack

ajcos

Adding my voice to @jontyb's suggestion. Just to explain my own use-case, I (also) have keys stored in my vault that I don't want to have to archive to remove from eligibility.

I also want to have different default keys configured on my work laptop and my personal machine, but I'm ok with the current solution of referencing public keys in my ~/.ssh/config file to configure that.

I'm loving the SSH support in general, though - it was a lovely surprise last year!

Cheers,
Cos.

Jack.P_1P

Hi @ajcos:

Glad to hear you liked the surprise of the SSH agent, I was pretty thrilled when it launched as well! 😀

As my colleague Jody shared, we're looking at improvements on how to manage and choose keys, but I don't have any timelines to share just yet. Stay tuned!

Jack

VJmes

Hi All,

Saw this come up a few times that updating the ~/.ssh/config file with each new key sucks a bit. Did a little digging through the ssh-config manpage and discovered that many implementations of openSSH automatically expand some tokens at runtime. If you download the public-keys & save them using the hostname from 1Password you can save updating the ssh-config file each time by using something like:

Host * IdentityAgent \\.\pipe\openssh-ssh-agent IdentityFile D:/keys/%h.pub IdentitiesOnly yes

A full list of usable tokens can be found here -- https://www.man7.org/linux/man-pages/man5/ssh_config.5.html#TOKENS

This _should _ remove one of the pain-points here until a method of passing through hostname information to the ssh-agent is made available.

Regards,

James

Jack.P_1P

Hi @VJmes:

Thanks for sharing!

Jack

gmay

@Jack.P_1P / @jody.h_1P / @floris_1P - Sorry to mass tag, you've all sort of mentioned above about "looking at improvements" so not really sure who the best person is.

I just stumbled across this thread after hitting the same issue as everyone else. Really glad to hear you're looking in to ways to improve the user experience here. If I only had 6 keys or less this whole thing would be fantastic.

I'm a fairly new user (I bet you've had a lot of those since what's been going on at LP...) and I'm trying to roll the SSH Agent to my team but the key limits / lack of a way to specify a key is a bit of a killer.

Do you have any news on when the improvements might be rolled out? (any sort of timescale would be helpful)
Do you have any info on what the approach you're working on might be?

Many thanks,

akschu

Hello,

I'm constantly bumping into issues with ssh keys because I have several 1password accounts for several different organizations which puts my ssh key count too high to login to anything. I could have a long and complex .ssh/config file to define the keys, but what would work better for me is this ability:

1password create a sock per account. Instead of "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" use "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/-agent.sock"

This way I can define a different sock for different hosts and immediately break this up by account which would help a lot.

Another thing that would be handy is the ability to disable a key. Sometimes I want to store a key in 1password but that doesn't mean I want the agent to try it for every login. Give me a button in 1password to disable ssh agent for this specific key. Right now I've resorted to removing the key and attaching the keys as a file, but it's ugly.

Thanks,
schu

akschu

the -agent.sock above had brackets to note account name, but the forum ate them. Something like accountname-agent.sock.