mina-sshd
mina-sshd copied to clipboard
apache
org.apache.sshd.common.SshException: No more authentication methods available
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 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)
......
@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 : 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
UserInteractionon theSshClient. TheUserInteractionhas access to theClientSessionand 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!