[
https://issues.apache.org/jira/browse/SSHD-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418631#comment-17418631
]
Thomas Wolf commented on SSHD-1214:
-----------------------------------
In 2.7.0, the client tries by default the RSA key it found
(C:\Users\y00509705\.ssh\id_rsa) three times; with signature algorithms
rsa-sha2-512, then rsa-sha2-256, and finally with the deprecated SHA-1 based
ssh-rsa signature. The first two login-attempts fail. The server appears to be
configured to close the connection after two unsuccessful attempts.
If that key should work, then it appears the server only understands ssh-rsa.
If you have control of the server, update it to be able to deal with
rsa-sha2-512 or rsa-sha2-256 signatures. Otherwise configure the client to not
use rsa-sha2-512 or rsa-sha2-256, or to try ssh-rsa first.
If that key correctly does not work and you want to force using password
authentication, configure the client to not try that key at all.
How exactly you configure the client for either case depends on the precise
client implementation, and whether it uses an OpenSSH-style ~/.ssh/config file.
If so, {{IdentitiesOnly yes}} accomplishes the latter (unless that key is set
explicitly with {{IdentityFile}}), or you could remove {{publickey}}
authentication from {{PreferredAuthentications}} altogether for that host
entry. The former could be achieved via {{PubkeyAcceptedAlgorithms ^ssh-rsa}}
or {{PubkeyAcceptedKeyTypes ^ssh-rsa}}. (All these configs are client-side.)
Finally in an Apache MINA sshd client, you can control programmatically which
signature algorithms are used, and of course also which authentication methods
are tried by a client at all.
> sshd login success using sshd 2.6.0 but failure with sshd 2.7.0
> ---------------------------------------------------------------
>
> Key: SSHD-1214
> URL: https://issues.apache.org/jira/browse/SSHD-1214
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: wei yao
> Priority: Major
> Fix For: 2.6.0
>
> Attachments: error.txt, ok.txt
>
>
> Hi, dear team.
> I'am facing one issue that the following code could login to one ssh server
> with sshd 2.6.0 but fail with 2.7.0. The configuration of sshd_config is:
> PermitRootLogin yes
> PasswordAuthentication yes
> UseDNS no
> Protocol 2
> LogLevel VERBOSE
> MaxAuthTries 3
> PubkeyAuthentication yes
> RSAAuthentication yes
> IgnoreRhosts yes
> RhostsRSAAuthentication no
> HostbasedAuthentication no
> PermitEmptyPasswords no
> PermitUserEnvironment no
> Ciphers aes128-ctr,aes192-ctr,aes256-ctr
> ClientAliveInterval 300
> ClientAliveCountMax 0
> Banner /etc/issue.net
> MACs hmac-sha2-256,hmac-sha2-512
> StrictModes yes
> AllowTcpForwarding no
> AllowAgentForwarding no
> GatewayPorts no
> PermitTunnel no
> KexAlgorithms
> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
>
> the java code is following:
> {code:java}
> //
> public static String sshAndExecCommandThenGetResult(String ip, int port,
> String username, String password, String command){
> @Cleanup(value = "stop")
> SshClient client = SshClient.setUpDefaultClient();
> client.start();
> try (ClientSession session = client.connect(username, ip,
> port).verify(Duration.ofSeconds(20))
> .getSession()) {
> session.addPasswordIdentity(password); // for password-based
> authentication
> ClientSessionImpl c = (ClientSessionImpl)session;
> AuthFuture authFuture = session.auth();
> authFuture.verify(Duration.ofSeconds(10));
> return session.executeRemoteCommand(command);
> } catch (Exception e) {
> log.error(e.getMessage(), e);
> return "exception when exec command:" + e.getMessage();
> }
> {code}
> The debug log is in attachment.
> Please check. Thanks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
