[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
Still no activity in the upstream issue, however I think OpenSSH 8.9 offers a mechanism that can help avoiding hitting MaxAuthTries in some cases: "destination constraints", see documentation for -h in ssh- add(1). AIUI constraining should limit the number of keys tried against a given host, making reaching MaxAuthTries more difficult. More info: https://www.openssh.com/agent-restrict.html https://lwn.net/Articles/880458/ It is not clear to me if setting destination constraints also affects the order in which keys are tried (narrower scope => higher priority). Another workaround is preventing ssh to reach the agent: SSH_AUTH_SOCK= ssh -i -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
I have again updated the upstream case, but if they are not willing/convinced this won't happen as Ubuntu delta or we will have too many small scratches by being slightly different on this. So anyone affected/requesting this please chime in on the upstream bug. Dropping server-next as it can't be acted on as-is. ** Tags removed: server-next -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
@RCJ - can you help by testing the PPA that I provided and chime in on the upstream discussion to get things moving a bit better - just to show that people would really care about this feature. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
** Changed in: openssh (Debian) Status: Unknown => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
Filed upstream for a discussion at https://bugzilla.mindrot.org/show_bug.cgi?id=3153 and linked in the bug here. ** Bug watch added: OpenSSH Portable Bugzilla #3153 https://bugzilla.mindrot.org/show_bug.cgi?id=3153 ** Also affects: openssh via https://bugzilla.mindrot.org/show_bug.cgi?id=3153 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in portable OpenSSH: Unknown Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: Unknown Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
** Also affects: openssh (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203700 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: Unknown Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: Triaged Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
I have a PPA at: https://launchpad.net/~paelzer/+archive/ubuntu/bug-872145-ssh-prefer-user-configured-key I have tested and the "IdentityFile" directive in /etc/ssh/ssh_config does not count as "user defined". I'd have preferred if that would count as well, but for now at least preferring the "-i" is better than nothing and it seems to not need a major overhaul. But other than that, this seems to work. Former: $ 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 Becomes: $ 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 @Rob - could you give the PPA a try and report for your case the following once for the old and once for the PPAs ssh binary? $ ssh -i -v "echo 1" |& grep "Will attempt" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: Triaged Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
Without checking deeper I'm unsure if keys listed in e.g. /etc/ssh/ssh_config are considered as "userprovided" but lets give this a shot. Gladly the debug already contains "explicit" if id->userprovided is true. I usually get: 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: pael...@swarm.naarz.dyndns.org RSA ... agent debug1: Will attempt key: /home/paelzer/.ssh/id_dsa debug1: Will attempt key: /home/paelzer/.ssh/id_ecdsa debug1: Will attempt key: /home/paelzer/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/paelzer/.ssh/id_ed25519 debug1: Will attempt key: /home/paelzer/.ssh/id_ed25519_sk debug1: Will attempt key: /home/paelzer/.ssh/id_xmss with an -i set to a key that is in the agent, the defaults vanish. And since the key is listed & in the agent it is preferred already debug1: Will attempt key: /home/paelzer/.ssh/id_rsa.n RSA ... explicit agent 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 But if I create a new key and add it it is NOT preferrd (this is the bug in discussion here) 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: pael...@swarm.naarz.dyndns.org RSA ... agent debug1: Will attempt key: /tmp/testkey RSA ... explicit The explicit one is down below in the order since it isn't in the agent. A final solution might want to insert them somewhere else than the very top and/or might want to do similar with certificates. But for the test the attached patch could be enough. ** Patch added: "experimental-1872145.debdiff" https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+attachment/5357863/+files/experimental-1872145.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: Triaged Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
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(, 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. ** Bug watch added: OpenSSH Portable Bugzilla #1499 https://bugzilla.mindrot.org/show_bug.cgi?id=1499 ** Bug watch added: OpenSSH Portable Bugzilla #1937 https://bugzilla.mindrot.org/show_bug.cgi?id=1937 ** Bug watch added: Debian Bug tracker #203700 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203700 ** Changed in: openssh (Ubuntu) Status: New => Triaged ** Changed in: openssh (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: Triaged Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
** Tags added: id-5e5e7f1874c52821423d5bfd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
** Tags added: server-next -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
It also prefers configured key files over smart cards, causing similar issues. Luckily there is a work around for that by adding /dev/null as an identify file in the config, but that's super ugly. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1872145] Re: explicit key offered after all agent keys, auth can fail before explicit key used
** Summary changed: - explicit key offered after all agent keys, auth fails before explicit key used + explicit key offered after all agent keys, auth can fail before explicit key used -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1872145 Title: explicit key offered after all agent keys, auth can fail before explicit key used Status in openssh package in Ubuntu: New Bug description: A user creates an ssh key and specifies it on the cmdline with 'ssh -i new_key user@host'. The connection fails with the message "Too many authentication failures" displayed to the user. This would lead the user to believe that they failed to put the public portion of the new key on the destination and it will probably be hard for the average user to debug this. The root of this issue is that the user has a number of keys in ~/.ssh/ registered with their ssh agent. The ssh command is offering each of these keys from the agent to the remote system before trying the explicit key from the command line. There are enough agent keys to reach the failure limit (usually 5 keys) with the remote before they get to the explicit key. The solution today for the user is to head down into the ssh_config man page to find '-o IdentitiesOnly=yes' to skip the agent keys and only use the specified key. But they're unlikely to do this because '-i' in the ssh man page doesn't suggest this and they'd only look for this if they actually understood the root cause of the problem, which is a bit cruel. We should consider changing the order of the keys offered to the remote to use explicit keys first followed by agent keys. It would seem to me that this would honor the users intent of explicitly specifying a key to use. The current order makes this difficult for anyone fielding a user's authentication failure report as they must double check that ssh managed to actually try the key the user specified before it raised an error message about authentication failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1872145/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
