I used the arcfour256 algorithm to connect to the sshserver of mina-sshd and encountered an exception

[czldb2]

version：2.9.2

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

The following is the exception information：

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](http://org.apache.sshd.common.io/).nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:409)
        at [org.apache.sshd.common.io](http://org.apache.sshd.common.io/).nio2.Nio2Session$1.onCompleted(Nio2Session.java:382)
        at [org.apache.sshd.common.io](http://org.apache.sshd.common.io/).nio2.Nio2Session$1.onCompleted(Nio2Session.java:377)
        at [org.apache.sshd.common.io](http://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](http://org.apache.sshd.common.io/).nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
        at [sun.nio.ch](http://sun.nio.ch/).Invoker.invokeUnchecked(Invoker.java:126)
        at [sun.nio.ch](http://sun.nio.ch/).Invoker$2.run(Invoker.java:218)
        at [sun.nio.ch](http://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)

[czldb2]

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.

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.

What is the configuration of mina-sshd or what configuration can I do on the target device to solve it?

[tomaswolf]

No idea. I just tested arcfour128 and arcfour256 against an OpenSSH 7.4 server in CentOS 7.9 (2009), and an Apache MINA SSHD 2.13.0-SNAPSHOT client works just fine. Maybe try the latest release 2.12.1, or the 2.13.0-SNAPSHOT available from the Apache snapshot repositories.

[czldb2]

No idea. I just tested arcfour128 and arcfour256 against an OpenSSH 7.4 server in CentOS 7.9 (2009), and an Apache MINA SSHD 2.13.0-SNAPSHOT client works just fine. Maybe try the latest release 2.12.1, or the 2.13.0-SNAPSHOT available from the Apache snapshot repositories.

I tried version 1.21.1 to connect and the problem still exists. Some other phenomena I have noticed so far:

• Connecting devices on the Intranet will fail, but devices connecting to cloud server vendors can succeed.
• The 1.7.0 version can be used to connect to Intranet devices.

[czldb2]

No idea. I just tested arcfour128 and arcfour256 against an OpenSSH 7.4 server in CentOS 7.9 (2009), and an Apache MINA SSHD 2.13.0-SNAPSHOT client works just fine. Maybe try the latest release 2.12.1, or the 2.13.0-SNAPSHOT available from the Apache snapshot repositories.

I found that when using arcfour256 algorithm, if the mac algorithm uses [email protected], The [email protected] or [email protected] algorithm will work, but any other mac algorithm will fail.

version: 2.9.2 sshd_config:

Protocol 2
Port 22
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UseDNS yes
UsePAM yes
X11Forwarding yes
UsePrivilegeSeparation sandbox
AcceptEnv LANG LC_*
Subsystem sftp /usr/libexec/openssh/sftp-server

[tomaswolf]

OK, thank you. Essentially: arcfour256 works only with the hmac-*-etm MACs.

This is a bug; it's caused by wrong block sizes being set. Yes, arcfour128 and arcfour256 are stream ciphers, but a block size must be set anyway because SSH RFC 4253 insists that

Note that 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. RFC 4253, section 6

So for arcfour128 and arcfour256, the "blocksize" must be 8.

Unfortunately, this is wrong at https://github.com/apache/mina-sshd/blob/71b842f759f9879d7638bed175e5be006d9c0f46/sshd-common/src/main/java/org/apache/sshd/common/cipher/BuiltinCiphers.java#L118 and at https://github.com/apache/mina-sshd/blob/71b842f759f9879d7638bed175e5be006d9c0f46/sshd-common/src/main/java/org/apache/sshd/common/cipher/BuiltinCiphers.java#L129

The last parameter must not be 16 or 32 but 8. arcfour128 works by chance, arcfour256 will fail for small packets.

I'll push a fix soon.

[tomaswolf]

Thank you for your investigations. This is fixed with commit 5a78e6d.