Comment 2 for bug 1872145

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.