[Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
Christian Ehrhardt
1872145 at bugs.launchpad.net
Wed Apr 22 09:21:24 UTC 2020
Without checking deeper I'm unsure if keys listed in e.g.
/etc/ssh/ssh_config are considered as "userprovided" but lets give this
a shot.
Gladly the debug already contains "explicit" if id->userprovided is
true.
I usually get:
debug1: Will attempt key: /home/paelzer/.ssh/id_rsa RSA ... agent
debug1: Will attempt key: ubuntu at cpaelzer-bastion RSA ... agent
debug1: Will attempt key: paelzer at lap RSA ... agent
debug1: Will attempt key: paelzer at swarm.naarz.dyndns.org RSA ... agent
debug1: Will attempt key: /home/paelzer/.ssh/id_dsa
debug1: Will attempt key: /home/paelzer/.ssh/id_ecdsa
debug1: Will attempt key: /home/paelzer/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/paelzer/.ssh/id_ed25519
debug1: Will attempt key: /home/paelzer/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/paelzer/.ssh/id_xmss
with an -i set to a key that is in the agent, the defaults vanish.
And since the key is listed & in the agent it is preferred already
debug1: Will attempt key: /home/paelzer/.ssh/id_rsa.n RSA ... explicit agent
debug1: Will attempt key: /home/paelzer/.ssh/id_rsa RSA ... agent
debug1: Will attempt key: ubuntu at cpaelzer-bastion RSA ... agent
debug1: Will attempt key: paelzer at lap RSA ... agent
But if I create a new key and add it it is NOT preferrd (this is the bug in discussion here)
debug1: Will attempt key: /home/paelzer/.ssh/id_rsa RSA ... agent
debug1: Will attempt key: ubuntu at cpaelzer-bastion RSA ... agent
debug1: Will attempt key: paelzer at lap RSA ... agent
debug1: Will attempt key: paelzer at swarm.naarz.dyndns.org RSA ... agent
debug1: Will attempt key: /tmp/testkey RSA ... explicit
The explicit one is down below in the order since it isn't in the agent.
A final solution might want to insert them somewhere else than the very
top and/or might want to do similar with certificates. But for the test
the attached patch could be enough.
** Patch added: "experimental-1872145.debdiff"
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+attachment/5357863/+files/experimental-1872145.debdiff
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1872145
Title:
explicit key offered after all agent keys, auth can fail before
explicit key used
Status in openssh package in Ubuntu:
Triaged
Bug description:
A user creates an ssh key and specifies it on the cmdline with 'ssh -i
new_key user at host'. The connection fails with the message "Too many
authentication failures" displayed to the user.
This would lead the user to believe that they failed to put the public
portion of the new key on the destination and it will probably be hard
for the average user to debug this.
The root of this issue is that the user has a number of keys in
~/.ssh/ registered with their ssh agent. The ssh command is offering
each of these keys from the agent to the remote system before trying
the explicit key from the command line. There are enough agent keys
to reach the failure limit (usually 5 keys) with the remote before
they get to the explicit key.
The solution today for the user is to head down into the ssh_config
man page to find '-o IdentitiesOnly=yes' to skip the agent keys and
only use the specified key. But they're unlikely to do this because
'-i' in the ssh man page doesn't suggest this and they'd only look for
this if they actually understood the root cause of the problem, which
is a bit cruel.
We should consider changing the order of the keys offered to the
remote to use explicit keys first followed by agent keys. It would
seem to me that this would honor the users intent of explicitly
specifying a key to use.
The current order makes this difficult for anyone fielding a user's
authentication failure report as they must double check that ssh
managed to actually try the key the user specified before it raised an
error message about authentication failures.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions
More information about the foundations-bugs
mailing list