| Summary: | Prefer user specified keys to avoid the agent overloading MaxAuthTries before even trying the key that was specified | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Christian Ehrhardt <christian.ehrhardt> | ||||||
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | enhancement | CC: | bugtrack, djm | ||||||
| Priority: | P5 | ||||||||
| Version: | 8.2p1 | ||||||||
| Hardware: | Other | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
|
Description
Christian Ehrhardt
2020-04-23 16:36:34 AEST
Example effect of the patch: Former behavior on a server with MaxAuthTries 4 the explicitly specified key would not have been tried: $ ssh -i /tmp/testkey -v horsea "echo 1" |& grep "Will attempt" debug1: Will attempt key: /home/paelzer/.ssh/id_rsa RSA ... agent debug1: Will attempt key: ubuntu@cpaelzer-bastion RSA ... agent debug1: Will attempt key: paelzer@lap RSA ... agent debug1: Will attempt key: paelzer@swarm.n RSA ... agent debug1: Will attempt key: /tmp/testkey RSA ... explicit With the change becomes this and works: $ ssh -i /tmp/testkey -v horsea "echo 1" |& grep "Will attempt" debug1: Will attempt key: /tmp/testkey RSA ... explicit debug1: Will attempt key: /home/paelzer/.ssh/id_rsa RSA ... agent debug1: Will attempt key: ubuntu@cpaelzer-bastion RSA ... agent debug1: Will attempt key: paelzer@lap RSA ... agent debug1: Will attempt key: paelzer@swarm.n RSA ... agent Created attachment 3387 [details]
identitiesOnly=explicit
maybe we could do something like this: allow IdentitiesOnly=explicit to disable adding agent keys that aren't explicitly listed as IdentityFiles/-i
Hi Damien, the suggested IdentitiesOnly=explicit is interesting, but it won't cover the part of the users that need the fix the most. I was mostly thinking about the less experienced users - those who'd not understand why things are failing and not know how to hunt for the existing workarounds. The IdentitiesOnly=explicit option would only fix it for those people that know what is going on (as they need to set it) unless if it would be the default config value. But as default it would break plenty of other use cases. But thinking about configs, maybe we'd want/need to go a step further. Today the preference order is in the code, maybe we'd want to expose that as a config. With my patch applied we have 6 classes of Auth to offer. We might apply my patch, but then revamp it completely to have the order configurable. The following would represent the order with my patch applied: IdentitiesOrder=key-explicit,cert-configured,cert-other,key-agent-configured,key-agent,key-other Everyone is welcome to bikeshed on the terms, but it actually was more about discussing the idea :-) I cannot understand what is issue with agent keys. User start agent and adds some keys(identities). It is expected those keys to take precedence over all other keys as they are loaded first! Then when is started client it could add other identities. Directive IdentitiesOnly set to yes is intended to minimize used agent keys. Sample: agent with keys agent1 agent2 agent3 To simplify let assume that configuration does no add other identities. a) client .. -i no_agent -i agent2 .. If IdentitiesOnly is set to yes client should try "agent2" and "no_agent". b) client .. -i no_agent .. If IdentitiesOnly is set to yes client should try only "no_agent". So I cannot see why IdentitiesOnly=yes is not solution. Reading OpenSSH manual page I partially agree with first report: ---- -i identity_file Selects a file from which the identity (private key) for public key authentication is read. The default is .... Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files). ---- The only things missing is that ssh(1) does not suggest for more details user to see directive IdentityFile ssh_config(5) where: ---- IdentityFile ... Additionally, any identities represented by the authentication agent will be used for authentication unless IdentitiesOnly is set. ... ---- "Additionally" is not appropriate word as agent keys are loaded first and is expected to be used first. It seems to me this report is just documentation issue. Hi Roumen, I can absolutely see your POV that I'd like to summarize "if you read/know all of the documentation you see what happens". And I can follow your argument that from there the obvious improvement would be to enhance the docs to be more obvious. But if I turn it around to the users perspective I'd rather convinced of the proposed behavior: user-Example A) If we describe 100 admins the following scenario: 1. ssh agent has 5 keys loaded 2. you run ssh -i ExplicitKey foo@bar And we then ask them "Do you expect that ExplicitKey will be tried?" I'm pretty sure the majority will answer "yes it will try ExplicitKey". And even if you then hint at MaxAuthTries limiting the amount that can be tried I assume that most would expect "what I specified explicitly would go first, since after all I specified it explicitly". user-Example B) What currently happens to users is something like: 1. `ssh -i ExplicitKey foo@bar` works fine 2. .. N. some other actions which eventually make ssh-agent hold >= MaxAuthTries other keys 3. `ssh -i ExplicitKey foo@bar` suddenly fails now 4. Puzzled ?!?, after a long time finding the subtle details of Agent/MaxAuthTries and wishes that at least what he specified explicitly would have been tried. Improved-Messaging example C) Turning the case around again (no offense please, this example is phrased slightly provocative to show my point). If the behavior isn't changed, then I'd suggest instead of a doc change that people first have to fail, then find the doc then understand it all ... Instead if ssh gives up failing before the key on the commandline was even tried ssh could emit a slightly different error. Instead of "Too many authentication failures" It could say: "Too many authentication failures, But just so you know, the key you thought you use wasn't even tried" I hope that helps to clarify why I think IdentitiesOnly and/or the documentation thereof isn't enough. Thanks in advance, Christian |