12 ms·

This can become problematic if you're using an SSH agent and have 4+ keys loaded into it. The problem is that your agent will step through keys to try auth with

by dice 10y ago

This can become problematic if you're using an SSH agent and have 4+ keys loaded into it. The problem is that your agent will step through keys to try auth with, but most OpenSSH servers will reject keys after 3 failed attempts. This means that you also need to keep an up-to-date entry in ~/.ssh/config as to which key to use with which system.

matthewaveryusa 10y ago
*6 attempts, I just looked that up today :)
ak4g 10y ago
Do people not already do this? I don't really make an effort to use a different keypair for every service, but I ran into the the max-attempts thing very soon after I started using ssh-agent, and so I do have to keep my .ssh/config up-to-date. I assumed the benefit for ssh-agent was in not having to retype the passphrase for each connection, not for it to try every keypair for every login.
niftich 10y ago
Is there a way to specify the hashed key fingerprint (or a just-long-enough subset of the key fingerprint) instead, as you try to authenticate to a specific host? Or an interactive key selection on the command-line? With a 'Remember my choice' option. These could be relatively easy UI enhancements for a command-line SSH agent.
- frumiousirc 10y ago
  With the agent the -i flag or IdentityFile config option is not honored. You then must maintain different agents, one for each distinct set of keys you want to use. The ssh-ident package helps do this. Or, you must insert a filter proxy between the real agent and the ssh client. The ssh-agent-filter package helps do this.
kerkeslager 10y ago
That's true, but I keep an up-to-date entry for each of my servers in my ~/.ssh/config anyway. Some of them don't even have hostnames; they only have IPs. I can't imagine having to remember that.
mook 10y ago
That is very annoying; luckily, it's possible to use %h and other variables to embed the remote host name in the file name of the key. Definitely useful to also have IdentitiesOnly set to avoid the automatic attempts, though.
walrus01 10y ago
Or just manually specify which keyset to use with the SSH "-i" identity option for the specific thing you're connecting to. I could have a hundred different public/private key sets stored in my ~/.ssh/ if necessary.

by dice 10y ago

matthewaveryusa 10y ago

*6 attempts, I just looked that up today :)

ak4g 10y ago

Do people not already do this? I don't really make an effort to use a different keypair for every service, but I ran into the the max-attempts thing very soon after I started using ssh-agent, and so I do have to keep my .ssh/config up-to-date. I assumed the benefit for ssh-agent was in not having to retype the passphrase for each connection, not for it to try every keypair for every login.

niftich 10y ago

Is there a way to specify the hashed key fingerprint (or a just-long-enough subset of the key fingerprint) instead, as you try to authenticate to a specific host? Or an interactive key selection on the command-line? With a 'Remember my choice' option. These could be relatively easy UI enhancements for a command-line SSH agent.

frumiousirc 10y ago
With the agent the -i flag or IdentityFile config option is not honored. You then must maintain different agents, one for each distinct set of keys you want to use. The ssh-ident package helps do this. Or, you must insert a filter proxy between the real agent and the ssh client. The ssh-agent-filter package helps do this.

kerkeslager 10y ago

That's true, but I keep an up-to-date entry for each of my servers in my ~/.ssh/config anyway. Some of them don't even have hostnames; they only have IPs. I can't imagine having to remember that.

mook 10y ago

That is very annoying; luckily, it's possible to use %h and other variables to embed the remote host name in the file name of the key. Definitely useful to also have IdentitiesOnly set to avoid the automatic attempts, though.

walrus01 10y ago

Or just manually specify which keyset to use with the SSH "-i" identity option for the specific thing you're connecting to. I could have a hundred different public/private key sets stored in my ~/.ssh/ if necessary.