I configured my client to enable only arcfour256 algorithm, and then the server connecting to mina-sshd will encounter this exception, and the client connecting to a device supporting only arcfour256 algorithm through mina-sshd will also encounter this exception. But I'm fine with using the client connection directly
I have tried arcfour128 and other algorithms with higher security to perform connection operation through mina-sshd component, and the connection can be normal now.
When arcfour256 algorithm is used, it is normal to connect the target device directly through the xshell client, but the connection using the mina-sshd component will be abnormal.
When using the arcfour256 algorithm, I switched the openssh version of the target device in the scenario where the mina-sshd component was used to connect to the target device, and neither 5.3 nor 7.4 could be connected properly, nor could the target device in different network segments be connected properly.
Exception in thread "main" org.apache.sshd.common.SshException: [ssh-connection]: Failed (IllegalArgumentException) to execute: Bad arguments
at org.apache.sshd.common.future.AbstractSshFuture.lambda$verifyResult$2(AbstractSshFuture.java:146)
at org.apache.sshd.common.future.AbstractSshFuture.formatExceptionMessage(AbstractSshFuture.java:206)
at org.apache.sshd.common.future.AbstractSshFuture.verifyResult(AbstractSshFuture.java:145)
at org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:56)
at org.apache.sshd.client.future.DefaultAuthFuture.verify(DefaultAuthFuture.java:35)
at org.apache.sshd.common.future.VerifiableFuture.verify(VerifiableFuture.java:121)
at sshTools.SshClientTool.createConnect(SshClientTool.java:213)
at sshTools.SshClientTool.main(SshClientTool.java:70)
Caused by: java.lang.IllegalArgumentException: Bad arguments
at javax.crypto.Cipher.update(Cipher.java:1941)
at org.apache.sshd.common.cipher.BaseCipher.update(BaseCipher.java:122)
at org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1644)
at org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:505)
at org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
at org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:409)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:382)
at org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:377)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
at sun.nio.ch.Invoker$2.run(Invoker.java:218)
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
When I was debugging, I found that the parameter of the eighth packet was changed to -8, which led to subsequent exceptions.
Could it be that inCipherSize may not work for stream encryption algorithms? (such as arcfour256, also known as RC4), because stream encryption algorithms do not use the block concept.
Arcfour is a stream cipher. The padding must then be such that the total SSH packet size is a multiple of 8. See RFC 4253: "the length of the concatenation of 'packet_length', 'padding_length', 'payload', and 'random padding' MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced, even when using stream ciphers."
Previous code had 16 and 32 as "block size" for these ciphers, which is wrong. Set it to 8.
Reference:https://github.com/apache/mina-sshd/commit/5a78e6dfe37ec982de8eec7abf449e83b3c984ae
