The arcfour256 algorithm fails to be configured with a specific mac algorithm #493

czldb2 · 2024-04-29T07:27:49Z

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 · 2024-04-30T02:20:56Z

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 · 2024-05-05T19:39:53Z

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 · 2024-05-06T03:54:33Z

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 · 2024-05-15T08:48:16Z

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 hmac-sha1-etm@openssh.com, The hmac-sha2-256-etm@openssh.com or hmac-sha2-512-etm@openssh.com 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 · 2024-05-16T20:47:28Z

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

mina-sshd/sshd-common/src/main/java/org/apache/sshd/common/cipher/BuiltinCiphers.java

Line 118 in 71b842f

arcfour128(Constants.ARCFOUR128, 8, 0, 16, "ARCFOUR", 128, "RC4", 16) {

and at

mina-sshd/sshd-common/src/main/java/org/apache/sshd/common/cipher/BuiltinCiphers.java

Line 129 in 71b842f

arcfour256(Constants.ARCFOUR256, 8, 0, 32, "ARCFOUR", 256, "RC4", 32) {

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.

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."[1] Previous code had 16 and 32 as "block size" for these ciphers, which is wrong. Set it to 8. The wrong values 16 and 32 were added by mistake in commit 1166a5d in version 2.2.0. [1] https://datatracker.ietf.org/doc/html/rfc4253#page-7 Bug: #493

tomaswolf · 2024-05-16T21:48:58Z

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

czldb2 closed this as completed Apr 29, 2024

czldb2 reopened this Apr 29, 2024

tomaswolf self-assigned this May 16, 2024

tomaswolf added the bug An issue describing a bug in the code label May 16, 2024

tomaswolf closed this as completed May 16, 2024

tomaswolf added this to the 2.13.0 milestone May 16, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

The arcfour256 algorithm fails to be configured with a specific mac algorithm #493

The arcfour256 algorithm fails to be configured with a specific mac algorithm #493

czldb2 commented Apr 29, 2024 •

edited

czldb2 commented Apr 30, 2024 •

edited

tomaswolf commented May 5, 2024

czldb2 commented May 6, 2024

czldb2 commented May 15, 2024 •

edited

tomaswolf commented May 16, 2024

tomaswolf commented May 16, 2024

The arcfour256 algorithm fails to be configured with a specific mac algorithm #493

The arcfour256 algorithm fails to be configured with a specific mac algorithm #493

Comments

czldb2 commented Apr 29, 2024 • edited

version：2.9.2

The following is the exception information：

czldb2 commented Apr 30, 2024 • edited

tomaswolf commented May 5, 2024

czldb2 commented May 6, 2024

czldb2 commented May 15, 2024 • edited

tomaswolf commented May 16, 2024

tomaswolf commented May 16, 2024

czldb2 commented Apr 29, 2024 •

edited

czldb2 commented Apr 30, 2024 •

edited

czldb2 commented May 15, 2024 •

edited