apache / mina-sshd

Apache MINA sshd is a comprehensive Java library for client- and server-side SSH.
https://mina.apache.org/sshd-project/
Apache License 2.0
847 stars 353 forks source link

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

Closed czldb2 closed 1 month ago

czldb2 commented 2 months ago

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 commented 2 months ago

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.

企业微信截图_17144434873491

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 commented 2 months ago

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 commented 2 months ago

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:

czldb2 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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