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

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!

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 :)

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

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.

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

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

Hi @VJmes:

Thanks for sharing!

Jack

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

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

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