[Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used

[Christian Ehrhardt ]

There are plenty of workarounds and the internet is full of this issue.
- https://serverfault.com/questions/36291/how-to-recover-from-too-many-authentication-failures-for-user-root
- https://www.tecmint.com/fix-ssh-too-many-authentication-failures-error/
- https://superuser.com/questions/187779/too-many-authentication-failures-for-username
- https://blog.jasonmeridth.com/posts/ssh-too-many-authentication-failures/
- https://security.stackexchange.com/questions/65120/ssh-always-too-many-authentication-failures
- https://www.unixtutorial.org/ssh-too-many-authentication-failures

Workarounds range from "set to PW auth only" via "disable the agent" to "don't use an agent".
But they are all just workarounds, even those modifying "PreferredAuthentications" can't set "commandline before agent" as "publickey" is just one entry in that list - there just is no differentiation between coming from agent or commandline in this argument.

In fact the issue is so common, there must be an official discussion
with the ssh community somewhere. I just haven't found it yet for all
the help-forums that are higher in the search results.

If forcing the search engines a bit the results are manyfold but old and new all just refer to the workarounds as far as I could see:
- https://lists.mindrot.org/pipermail/openssh-unix-dev/2003-December/019931.html
- https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035029.html
- ...

There are many "related but not entirely the same" upstream bugs:
- https://bugzilla.mindrot.org/show_bug.cgi?id=1499
- https://bugzilla.mindrot.org/show_bug.cgi?id=1937
...
But none I could find asked for the simple suggestion here of letting the "-i" to be "in front" of the agent-identities.

This issue is old as I mentioned…
There might be other launchpad bugs as well, but just to show how old this is of 2003 and still open
=> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203700


In the code they register -i/configured keys in readconf.c:add_identity_file.
There the code even differs between those picked up by default config vs those specified by the user.
For any key in options->identity_files[n] options->identity_file_userprovided[n] will be != 0 if provided by the user.

In sshconnect2.c:pubkey_prepare then it builds the list of keys to present.
Per function header that is:
1551  * try keys in the following order:
1552  * »1. certificates listed in the config file
1553  * »2. other input certificates
1554  *»·3. agent keys that are found in the config file
1555  *»·4. other agent keys
1556  *»·5. keys that are only listed in the config file

That flag is carried over when building the list:
1595 »···»···id->userprovided = options.identity_file_userprovided[i];
1596 »···»···TAILQ_INSERT_TAIL(&files, id, next);
The same is true for "certificates" in the list called "preferred"

Agent keys are in the list "agent".
If a key from the "agent" is equal to one in "files" it is dequeued from "files" and inserted at the tail of "preferred".
Then the remaining agent keys are transferred to "preferred".
This makes the prio list mentioned above.

Eventually it Tail-appends the rest of the "files" list to "preferred"
That list is then filtered for the PubkeyAcceptedKeyTypes option and used.

The end result is in the list "preferred" and what is listed in order in "ssh -v" as:
  Will attempt key: ...

This surely needs an upstream discussion, but we could make a PoC for it
- try it with a few people here and then go for upstream.

** Bug watch added: OpenSSH Portable Bugzilla #1499
   https://bugzilla.mindrot.org/show_bug.cgi?id=1499

** Bug watch added: OpenSSH Portable Bugzilla #1937
   https://bugzilla.mindrot.org/show_bug.cgi?id=1937

** Bug watch added: Debian Bug tracker #203700
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203700

** Changed in: openssh (Ubuntu)
       Status: New => Triaged

** Changed in: openssh (Ubuntu)
   Importance: Undecided => Wishlist

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