https://bugzilla.mindrot.org/show_bug.cgi?id=3153
Ben <b...@smokingkangaroo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |b...@smokingkangaroo.com --- Comment #6 from Ben <b...@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. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs