org.apache.sshd.common.SshException: No more authentication methods available

[winds91]

Version

2.11.0

Bug description

Java远程银河麒麟V10服务器时，首先可以确定的是密码是对的，而且服务器也开启了密码验证登录，并且通过Xshell工具可以访问。现在通过mina-sshd连接时，抛出了异常，如下：
（When attempting to connect to a Kylin V10 server remotely using Java, it is certain that the password is correct, and password-based authentication is enabled on the server, confirmed by successful access through Xshell. However, when trying to establish a connection using mina-sshd, an exception is thrown.）

org.apache.sshd.common.SshException: No more authentication methods available

Actual behavior

银河麒麟V10服务器 支持密码连接，并且确定密码是对的（The Kylin V10 server supports password-based connections, and it is confirmed that the password is correct.）

Expected behavior

应该能够正常连接才对（It should be possible to connect normally.）

Relevant log output

No response

Other information

No response

[tomaswolf]

I have no Kylin V10, so I cannot check. Post full debug logs.

[cslgo]

@tomaswolf
I also encountered the same problem.
Directly using SshClient to add is OK, but using ClientSession instead will report an exception: org.apache.sshd.common.SshException: No more authentication methods available
more details:

   @Test
    public void testProxyWithHostKeyVerificationAndCustomConfig3() throws Exception {
        try (SshClient client = setupTestClient()) {
            client.setServerKeyVerifier(AcceptAllServerKeyVerifier.INSTANCE);
           //Connect via the proxy
            client.setHostConfigEntryResolver(HostConfigEntry.toHostConfigEntryResolver(Arrays.asList(
                    new HostConfigEntry("server", "ip1", 22, "root", "proxy"),
                    new HostConfigEntry("proxy", "ip2", 22, "root"))));
            client.start();
            //auth is ok !
            //client.addPasswordIdentity("pass@xord123");
            //client.addPasswordIdentity("cloxi!#@048987");
            ConnectFuture verifySession = client.connect("server").verify(CONNECT_TIMEOUT);
            if (!verifySession.isConnected()) {
                logger.error("Session connect failed after {} mill seconds", CONNECT_TIMEOUT);
                throw new RuntimeException(
                        "Session connect failed after " + CONNECT_TIMEOUT + " mill seconds.");
            }
            try (ClientSession session = verifySession.getSession()) {
                //but throw an exception
                session.addPasswordIdentity("pass@word123");
                session.addPasswordIdentity("cloxi!544048987");
                session.auth().verify(AUTH_TIMEOUT);

                assertTrue(session.isOpen());
                doTestCommand(session, "ls -la");
            }
            // make sure the proxy session is closed / closing
            assertTrue(proxySession == null || proxySession.isClosing() || proxySession.isClosed());
        }
    }

console printout：

Finished com.chinamobile.cmdi.framework.util.ssh.ProxyTest:testProxyWithHostKeyVerificationAndCustomConfig3 in 77640 ms

org.apache.sshd.common.SshException: No more authentication methods available

	at org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:141)
	at org.apache.sshd.client.future.DefaultConnectFuture.verify(DefaultConnectFuture.java:55)
	at org.apache.sshd.client.future.DefaultConnectFuture.verify(DefaultConnectFuture.java:36)
	at org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:74)
	at com.chinamobile.cmdi.framework.util.ssh.ProxyTest.testProxyWithHostKeyVerificationAndCustomConfig3(ProxyTest.java:239)
......

[tomaswolf]

@cslgo : yours is not the same problem as the original report. In the original report I don't see any proxy jump, but you are doing a proxy jump.

Proxy jumps with password auth cannot work that way. The implementation in Apache MINA sshd has problems anyway (see #318), and I don't think it can work with password auth in this way at all. The point is that a proxy jump creates nested SSH sessions, but you get only access to the final, outermost session to connect to the target server. So any passwords you set on that session apply only to the final session connected to the target server.

If you set the passwords on the SshClient, they are tried for any session, proxy and target. This may work, but gives at least one failed log-in attempt at either the proxy or at the target before succeeding.

If you set the passwords on the target session: the nested session for the proxy still has no password. Hence the connection fails.

Proxy jumps work best if one uses publickey authentication configured via the HostConfigEntries. If you absolutely want to use passwords, try setting a UserInteraction on the SshClient. The UserInteraction has access to the ClientSession and can thus provide the appropriate password based on user name and session remote address, or it can prompt for the password.

[cslgo]

@cslgo : yours is not the same problem as the original report. In the original report I don't see any proxy jump, but you are doing a proxy jump.

Proxy jumps with password auth cannot work that way. The implementation in Apache MINA sshd has problems anyway (see #318), and I don't think it can work with password auth in this way at all. The point is that a proxy jump creates nested SSH sessions, but you get only access to the final, outermost session to connect to the target server. So any passwords you set on that session apply only to the final session connected to the target server.

If you set the passwords on the SshClient, they are tried for any session, proxy and target. This may work, but gives at least one failed log-in attempt at either the proxy or at the target before succeeding.

If you set the passwords on the target session: the nested session for the proxy still has no password. Hence the connection fails.

Proxy jumps work best if one uses publickey authentication configured via the HostConfigEntries. If you absolutely want to use passwords, try setting a UserInteraction on the SshClient. The UserInteraction has access to the ClientSession and can thus provide the appropriate password based on user name and session remote address, or it can prompt for the password.

The explanation is very clear. I understood the problem through your explanation. Thank you very much!

[fisher-andrew-m-aa]

Hi, are there any updates on the original problem? We're seeing this as well, with the same code producing either "No more authentication methods" or working perfectly with password authentication, seemingly at random within our application using Spring Integration's Mina abstraction (DefaultSftpSessionFactory).

I've seen recommendations to just go back to JSch using a custom ssh client, but we'd like to be able to use this out of the box without serious workarounds if possible.

[tomaswolf]

No. We never got any reply from the original reporter. Perhaps try 2.14.0-SNAPSHOT; we did make an unrelated change in the authentication code. (It was about #533, but perhaps it helps anyway.)

[fisher-andrew-m-aa]

That's unfortunate, but I'll give that a shot. Thank you.

[fisher-andrew-m-aa]

That didn't help. Is there any chance this can be looked at again?

I can unfortunately only provide client-side information, since in our case the server being connected to is hosted by an external third-party and we don't have access to its logs.

What I can say is that the previous Spring Integration implementation, which uses JSch, works without issue using the same passwords, and that the current Mina implementation also works correctly around half of the time, so I don't believe it to be a server-side issue.

[tomaswolf]

Of course it can be looked at. The issue is not closed :-) What kind of SSH server is it?

For starters we should figure out whether it is a problem in Apache MINA sshd, or in Spring Integration. Does the problem also occur (about half of the time) if you create a simple Apache MINA sshd client and connect to that server? If so, I would need full client-side logs at debug level for a connection where it worked, and for a connection where it didn't.

Does the problem occur if you use our SFTP bundle for Spring Integration instead of what Spring Integration provides? (Bundle sshd-spring-sftp.)

[fisher-andrew-m-aa]

It looks like we've found our issue.

We've apparently had a race condition related to getting SFTP sessions from the factory due to our architecture (application is handling many requests with differing credentials at once, but factory was defined as a Spring Bean with larger-than-request scope) for a very long time, but JSch would just quietly retry until the race resolved and then authenticate and get the session.

Mina (correctly) fails out and yells about authentication, presumably after the first password authentication fails, and then it can't find a key or anything else to use. Limiting the scope of the factory to the request level so it's only trying to use one set of credentials per request and not bleeding them over into other SFTP session opens appears to have solved the issue.

Thanks for your help with this!

[fragaLY]

So what is the problem actually?

I had an issue, I created at:

#622