Retry partial authentication with all remaining auth methods (Fixes #812) #820
Conversation
Signed-off-by: Jeroen van Erp <jeroen@hierynomus.com>
…ccess Signed-off-by: Jeroen van Erp <jeroen@hierynomus.com>
hierynomus
force-pushed
the
issue-812
branch
from
e43c672
to
d7dd73b
Compare
Codecov Report
@@ Coverage Diff @@
## master #820 +/- ##
============================================
- Coverage 64.84% 64.83% -0.02%
- Complexity 1467 1468 +1
============================================
Files 210 211 +1
Lines 8537 8553 +16
Branches 781 785 +4
============================================
+ Hits 5536 5545 +9
- Misses 2592 2597 +5
- Partials 409 411 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
| } else if (result == AuthResult.PARTIAL) { | ||
| // Put all remaining methods in the tried list, so that we can try them for the second round of authentication | ||
| while (it.hasNext()) { | ||
| tried.add(it.next()); |
There was a problem hiding this comment.
Suppose there are three keys loaded on the client: A, B, C. Also, suppose that the server knows only keys B and C, and requires both keys to be provided by the client. (-o AuthenticationMethods=publickey,publickey)
If I understand this code correctly, the authentication flow would work like this:
- SSHJ sends the public key A.
- The server responds "failure".
- SSHJ adds the public key A to
tried. - SSHJ sends public key B.
- The server responds "partial".
- SSHJ adds the last public key C to
triedand invokes authentication recursively. - SSHJ sends public key A again. It's definitely known that the server doesn't accept this key, because it already refused it.
- The server expectedly responds "failure".
- SSHJ sends the public key C.
- The server responds "success".
It becomes a severe problem for users who have dozens of keys, mostly coming from SSH agent. Also, it becomes a problem with paranoidal servers that have a small MaxAuthTries.
Instead, OpenSSH has a special workaround for public keys. It takes the keys from a round-robin collection, so definitely unacceptable keys are not re-sent again and again.
|
I can backport some of our changes with plenty of tests, though they're in Kotlin, which would require time for complete rewriting to Java. |
|
Sorry for taking so long to get to this. I tested this branch with nifi and unfortunately I still get the same error of "net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods" when the order is backwards from how the AuthMethods are added to the client. |
No description provided.