[Bug 3153] 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

Ben <ben at smokingkangaroo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ben at smokingkangaroo.com

--- Comment #6 from Ben <ben at smokingkangaroo.com> ---
The problem that arises isn't just overloading MaxAuthTries. Very
popular services like GitHub and BitBucket use the SSH key that is
presented to identify what the user has access to. So when you have
multiple accounts, you NEED to be able to control which exact identity
is used, rather than merely adding an identity to the set and letting
SSH try them in whatever order it decides.

I know the order IS determined, but in some very common setups (like
using AddKeysToAgent=yes and an agent with that times out keys) the set
of keys that are in the agent at any moment in time is essentially
"random", which means it becomes highly unstable which key SSH will
decide to present to a given host.

The core of the issue is: for the majority of options, setting them on
the command line takes precedence over those in the config files, but
there's no way to do that with identities. Explicitly passing an
identity on the command line *is* treated as "read first", so it's at
the head of the list and will be tried first by default. If that was
the end of the story it would be close enough to allowing ssh -i <key>
to work as an "override", as most other command line settings would do.

But SSH then re-orders the list of identities based on what's currently
in the agent, so if one of the keys you're trying to override is in the
agent and the one you passed on the command line is not, then it lets
the one you were trying to override take precedence. IdentitiesOnly is
completely unrelated to this aspect of the problem; it stops SSH from
trying ADDITIONAL keys it finds in the agent, but it doesn't give you
any way to express on the command line "definitely use THIS key".

This re-ordering only really makes sense if you assume that if multiple
keys could authenticate then any of them is equally good AND that you
can try as many keys as are configured until one succeeds. For a lot of
common use cases these assumptions don't seem to hold up.

We can work around when the "there's no limit on the number of keys you
can try" assumption is false (which was the problem in all of those
reports Christian linked to) by using IdentitiesOnly and carefully
crafting our configuration so that there only are a small enough number
of keys that SSH will try. But this at least you can configure
"privately" for yourself, and once you've set it up there's no manual
steps you need to make on each SSH call.

When the "all keys that work are equally good" assumption is false
(e.g. multiple GitHub accounts), the only workarounds I know are to set
up Host aliases (each with one key configured, and use IdentitiesOnly)
and use those instead of the real host, or else to configure multiple
IdentityFiles (or no IdentityFiles and use IdentitiesOnly=no) and
carefully manage which key is loaded in the agent. The host alias
workaround then can't be private if the SSH command is scripted and
shared with other developers (e.g. everyone working at Company123 needs
to know that Company123's private GitHub repositories should be
accessed as if they were at company123-github, not github.com), and
managing what keys are in the agent requires extra manual steps before
each SSH call. Neither option is something that can just be set on the
command line when a tool is calling SSH; they both require knowing
what's in the user's ssh config.

The change Christian originally proposed (where keys explicitly passed
on the command line keys are tried first EVEN if some other keys are
already loaded in the agent) would make it possible to use multiple
GitHub accounts nicely. Git can change the SSH command line, so you
tell it to add -i <the-right-key-for-this-repository> in the config for
certain repositories. If SSH would be guaranteed to try that key first
it would "just work" as an override of a default key specified in
~/.ssh/config. At present it can only be made to work if you don't have
a default set, and need to override the SSH command for every
repository. Alternatively, a setting that said "ignore any other keys
found in configuration read after this point" would also make this
usable (you could pass that setting on the command line along with -i
<key>).

Or alternatively alternatively, a setting to simply disable the
re-ordering based on the agent state would also work fine! Is there any
reason to do the reordering that other than maybe saving entering a
passphrase, if one of the already unlocked keys works? It seems to be
optimising for the wrong thing, in my opinion; I would rather be able
to control the order in which keys are tried, and I'm not sure I've
ever had a setup where I have multiple equally-good keys and it's
helpful for them to be chosen based on which happens to be unlocked.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.