Signing back into the Community for the first time? You'll need to reset your password to access your account. Find out more.
Forum Discussion
Ability to specify which key to use (otherwise: Too many authentication failures)
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
Hey Jack_P_1P apologies for not getting back earlier, but I did see this hit the release channel before I'd had the chance to test the nightly. Thanks very much for putting this in, it works great!
Jack_P_1P1Password Team
Hi @jenssgb and @Ekami67:
As of yesterday, 1Password for desktop now includes the ability to better customize which keys are used: SSH agent config file | Developer Documentation
Jack
Hi Jack_P_1P
Is there an update or roadmap to the SSH agent improvements?
I stumbled across the 6-SSH key limitation today, and it took me a while to figure it out.
Tip:
ssh -v <user>@<host>Adjusting the config file on my system and storing the key locally again breaks the complete advantage of 1Password for SSH.
@billvortex @Gudlyf @zaxaz @Ekami67 @digitalfiz @rodneyt @jontyb @yboulkaid @ajcos @VJmes gmay @akschu
The following features are now available to try on the Nightly release channel today:
- Control which SSH keys are enabled in the agent, even if they're from other vaults than the Private vault.
- Control the order in which keys are offered to SSH servers.
You can find more information, including instructions for the feature, by joining the
#ssh-agent-configchannel in our Slack workspace. It would be great to get your feedback.Next up is support for multiple agent config files/sockets, the earliest updates for which will be made in our Slack workspace.
floris_1P@jontyb @yboulkaid gmay @akschu
I wanted to let you know that we're working on a solution that allows for the following:
- Control which SSH keys are enabled in the agent, even if they're from other vaults than the Private vault.
- Control the order in which keys are offered to SSH servers.
- Create isolated setups with certain keys offered on a separate socket.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.- floris_1P
@akschu Being able to configure different sockets is something we're investigating! As for disabling keys, you can already do that now by moving them to a different vault. The agent will then ignore them, even if they're of the
SSH Keyitem type. There will be more customization on that front coming too.
