[Bug 3153] New: Prefer user specified keys to avoid the agent overloading MaxAuthTries before even trying the key that was specified

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3153

            Bug ID: 3153
           Summary: Prefer user specified keys to avoid the agent
                    overloading MaxAuthTries before even trying the key
                    that was specified
           Product: Portable OpenSSH
           Version: 8.2p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: christian.ehrhardt at canonical.com

Created attachment 3385
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3385&action=edit
RFC patch to start the discussion

Hi,
in a recent bug report to Ubuntu [1] I was wondering that this issue
seems to exist for so long and affect so many people
[2][3][4][5][6][7][8].
It was also discussed within openssh in [9][10].
But in all of those cases all that was done was to suggest workarounds
like "PubkeyAuthentication=no" or "IdentitiesOnly=yes", but IMHO those
are all just exactly that - workarounds.

Also there are many "related but not entirely the same" upstream bugs
like [11][12], but it seems no one has yet discussed the approach we
had in mind.

If a usual user calls ssh like
  ssh -i <mykey> ...
And gets:
  "Too many authentication failures"
He'd not even think about <mykey> not even being tried.

The problem is that the current order in pubkey_prepare will order
those directly specified keys too late.

 * try keys in the following order:
 *     1. certificates listed in the config file
 *     2. other input certificates
 *     3. agent keys that are found in the config file
 *     4. other agent keys
 *     5. keys that are only listed in the config file

Yes, if <mykey> is in the agent it will come at #3 which usually is
early enough.
But if <mykey> isn't in the agent which is usual for any new key that a
user created/tries it will come at #5.
If now the number of keys in #4 exceed the servers "i" the user gets
rejected without even trying <mykey> that he has specified.

Config may be config, but if a user specifies something directly on
invocation I'd expect it to supersede the configuration.

I'm clear that there might be more needed:
- has it to be ordered behind certs?
- do user-specified certs also need to get up in the list?
- does a test need to be added?
- discussion here about potential drawbacks
- ...

But I wanted to get things started and therefore I have attached a
sugegsted initial patch as well as a Ubuntu PPA [13] with it applied.

[1]: https://bugs.launchpad.net/debian/+source/openssh/+bug/1872145
[2]:
https://serverfault.com/questions/36291/how-to-recover-from-too-many-authentication-failures-for-user-root
[3]:
https://www.tecmint.com/fix-ssh-too-many-authentication-failures-error/
[4]:
https://superuser.com/questions/187779/too-many-authentication-failures-for-username
[5]:
https://blog.jasonmeridth.com/posts/ssh-too-many-authentication-failures/
[6]:
https://security.stackexchange.com/questions/65120/ssh-always-too-many-authentication-failures
[7]: https://www.unixtutorial.org/ssh-too-many-authentication-failures
[8]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203700
[9]:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2003-December/019931.html
[10]:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035029.html
[11]: https://bugzilla.mindrot.org/show_bug.cgi?id=1499
[12]: https://bugzilla.mindrot.org/show_bug.cgi?id=1937
[13]:
https://launchpad.net/~paelzer/+archive/ubuntu/bug-872145-ssh-prefer-user-configured-key

-- 
You are receiving this mail because:
You are watching the assignee of the bug.