You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Thomas Wolf (Jira)" <ji...@apache.org> on 2022/07/06 12:08:00 UTC
[jira] [Commented] (SSHD-1277) Error connecting to particular SFTP server after enabling HostKeyAlgorithms rsa-sha2-256 rsa-sha2-512 on SFTP client
[ https://issues.apache.org/jira/browse/SSHD-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563185#comment-17563185 ]
Thomas Wolf commented on SSHD-1277:
-----------------------------------
The client send in SSH_MSG_KEX_INIT the supported host key signature algorithms "ssh-rsa, ssh-dss,rsa-sha2-256,rsa-sha2-512". (Where does ssh-dss come from? From the code you've shown, it shouldn't be in there, should it? But that's irrelevant.)
The server in its own SSH_MSG_KEX_INIT sends "ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa".
According to [RFC 4253|https://datatracker.ietf.org/doc/html/rfc4253#section-7.1], negotiation of the server host key algorithms, "The first algorithm on the client's name-list that satisfies the requirements and is also supported by the server MUST be chosen".
Apache MINA sshd chooses "ssh-rsa". The server apparently chooses "rsa-sha2-256". So the two don't understand each other.
I've seen this [before|https://www.eclipse.org/forums/index.php/t/1108282/]. I have the impression "ssh-rsa" would be correct, and the server is wrong to send an "rsa-sha2-256" signature. (I.e., no bug in Apache MINA sshd. But maybe I'm missing something... KEX algorithm is "ecdh-sha2-nistp256".)
Specify the signature algorithms in the client in the order "rsa-sha2-512,rsa-sha2-256,ssh-rsa". Then client and server should both agree on the same signature algorithm, and the connection should work again.
> Error connecting to particular SFTP server after enabling HostKeyAlgorithms rsa-sha2-256 rsa-sha2-512 on SFTP client
> --------------------------------------------------------------------------------------------------------------------
>
> Key: SSHD-1277
> URL: https://issues.apache.org/jira/browse/SSHD-1277
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 2.8.0
> Environment: java.runtime = Java(TM) SE Runtime Environment (8.0.6.10 - pxa6480sr6fp10-20200408_01(SR6 FP10))
> os = Linux (3.10.0-1160.42.2.el7.x86_64; amd64) (en_US)
> Reporter: Roberto Deandrea
> Priority: Major
> Attachments: trace_apachesshd_client.log
>
>
> Hi Thomas,
> I have a strange issue with an SFTP client connection based on Apache SSHD 2.8.0 client.
> After enabling the support for server HostKeyAlgorithms rsa-sha2-256,rsa-sha2-512 with this code:
> _SshClient sshClient = SshClient.setUpDefaultClient();_
> _sshClient.setSignatureFactories(Arrays.<NamedFactory<Signature>> asList( BuiltinSignatures.rsa,_
> _BuiltinSignatures.rsaSHA256,_
> _BuiltinSignatures.rsaSHA512));_
>
> the SFTP connection fails against a particular server with the following stack trace :
> [6/28/22 5:32:46:783 EDT] 00004102 id=00000000 org.apache.sshd.common.util.logging.LoggingUtils W warn exceptionCaught(ClientSessionImpl[StateStreetDS.sftpuser@/127.0.0.1:46323])[state=Opened] SignatureException: Signature encoding error
> java.security.SignatureException: Signature encoding error
> at com.ibm.crypto.fips.provider.RSASignature.a(Unknown Source)
> at com.ibm.crypto.fips.provider.RSASignature.engineVerify(Unknown Source)
> at java.security.Signature$Delegate.engineVerify(Signature.java:1231)
> at java.security.Signature.verify(Signature.java:661)
> at org.apache.sshd.common.signature.AbstractSignature.doVerify(AbstractSignature.java:164)
> at org.apache.sshd.common.signature.SignatureRSA.verify(SignatureRSA.java:116)
> at org.apache.sshd.client.kex.DHGClient.next(DHGClient.java:181)
> at org.apache.sshd.common.session.helpers.AbstractSession.handleKexMessage(AbstractSession.java:633)
> at org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:524)
> at org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:452)
> at org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1524)
> at org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:412)
> at org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
> at org.apache.sshd.netty.NettyIoSession.channelRead(NettyIoSession.java:252)
> at org.apache.sshd.netty.NettyIoSession$Adapter.channelRead(NettyIoSession.java:296)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:271)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:820)
> Caused by: java.io.IOException: ObjectIdentifier mismatch: 2.16.840.1.101.3.4.2.1
> at com.ibm.crypto.fips.provider.RSASignature.decodeSignature(Unknown Source)
>
> +Before the above code change, the SFTP connection worked fine with that particular SFTP server.+
> The file attached contains verbose traces of the failing SFTP client connection.
> Looking through Apache SSHD Jiras and mails I found this mail (https://www.mail-archive.com/dev@mina.apache.org/msg33417.html) that shows the same symptoms of my problem. The problem was reported in Apache SSHD 2.2.0 and fixed in 2.4.0.
>
> Questions :
> Do you think this is a bug inside Apache SSHD 2.8.0 code ?
> How is possible that enabling rsa-sha2 host key algorithms on client could give this issue with a ('before') working SFTP connection ?
> Do you need other info for troubleshooting this issue ?
>
> Thanks in advance for your support
> Kind Regards
> Roberto D.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org