Retry partial authentication with all remaining auth methods (Fixes #812)

[hierynomus]

No description provided.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 59.09091% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.83%. Comparing base (6e7fb96) to head (d7dd73b).
⚠️ Report is 67 commits behind head on master.

Files with missing lines	Patch %	Lines
src/main/java/net/schmizz/sshj/SSHClient.java	50.00%	5 Missing and 1 partial ⚠️
...n/java/net/schmizz/sshj/userauth/UserAuthImpl.java	50.00%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@             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     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vladimirlagunov]

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 tried and 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.

[vladimirlagunov]

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.

[jamespowenjr]

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.