SSHD 2.14.0
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.13.2...sshd-2.14.0
- GH-524 Performance improvements
- GH-533 Fix multi-step authentication
- GH-582 Fix filtering in
NamedFactory
- GH-587 Prevent
NullPointerException
on closed channel inNettyIoSession
- GH-590 Better support for FIPS
- GH-597 Pass on
Charset
inClientSession.executeRemoteCommand()
- New utility methods
SftpClient.put(Path localFile, String remoteFileName)
andSftpClient.put(InputStream in, String remoteFileName)
facilitate SFTP file uploading.
GH-590 Better support for FIPS
Besides fixing a bug with bc-fips (the RandomGenerator
class exists in normal Bouncy Castle, but not in the FIPS version, but Apache MINA sshd referenced it even if only bc-fips was present), support was improved for running in an environment restricted by FIPS.
There is a new system property org.apache.sshd.security.fipsEnabled
. If set to true
, a number of crypto-algorithms not approved by FIPS 140 are disabled:
- key exchange methods sntrup761x25519-sha512, sntrup761x25519-sha512@openssh.com, curve25519-sha256, curve25519-sha256@libssh.org, curve448-sha512.
- the chacha20-poly1305 cipher.
- the bcrypt KDF used in encrypted private key files in OpenSSH format.
- all ed25519 keys and signatures.
Additionally, the new "SunJCEWrapper" SecurityProviderRegistrar
(see below) and the EdDSASecurityProviderRegistrar
are disabled, and the BouncyCastleScurityProviderRegistrar
looks only for the "BCFIPS" security provider, not for the normal "BC" provider.
If the system property is not set to true
, FIPS mode can be enabled programmatically by calling SecurityUtils.setFipsMode()
before any other call to Apache MINA sshd.
There is a new SecurityProviderRegistrar
that is registered by default if there is a SunJCE
security provider. It uses the AES and HmacSHA* implementations from SunJCE
even if Bouncy Castle is also registered. SunJCE
has native implementations, whereas Bouncy Castle may not.
The new registrar has the name "SunJCEWrapper" and can be configured like any other registrar. It can be disabled via the system property org.apache.sshd.security.provider.SunJCEWrapper.enabled=false
. It is also disabled in FIPS mode (see above).
GH-582 Fix filtering in NamedFactory
The methods NamedFactory.setupBuiltinFactories(boolean ignoreUnsupported, ...)
and NamedFactory.setupTransformedFactories(boolean ignoreUnsupported, ...)
had a bug that gave the "ignoreUnsupported" parameter actually the meaning of "include unsupported".
This was fixed in this release, but existing code calling these or one of the following methods:
BaseBuilder.setUpDefaultMacs(boolean ignoreUnsupported)
BaseBuilder.setUpDefaultCiphers(boolean ignoreUnsupported)
ClientBuilder.setUpDefaultCompressionFactories(boolean ignoreUnsupported)
ClientBuilder.setUpDefaultKeyExchanges(boolean ignoreUnsupported)
ClientBuilder.setUpDefaultSignatureFactories(boolean ignoreUnsupported)
ServerBuilder.setUpDefaultCompressionFactories(boolean ignoreUnsupported)
ServerBuilder.setUpDefaultKeyExchanges(boolean ignoreUnsupported)
ServerBuilder.setUpDefaultSignatureFactories(boolean ignoreUnsupported)
- any of the methods starting with
SshConfigFileReader.configure
SshClientConfigFileReader.configure(...)
SshServerConfigFileReader.configure(...)
should be reviewed:
- if the method is called with parameter value
true
, the result will no longer include unsupported algorithms. Formerly it wrongly did. - if the method is called with parameter value
false
, the result may include unsupported algorithms. Formerly it did not.
So if existing code used parameter value false
to ensure it never got unsupported algorithms, change it to true
.
- GH-536 The project now requires JDK 17 at build time, while the target runtime still remains unchanged to support JDK 8.
SSHD 2.13.2
- GH-525: Fix sntrup761x25519-sha512 by @tomaswolf in https://github.com/apache/mina-sshd/pull/528
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.13.1...sshd-2.13.2
SSHD 2.13.1
This release does not contain any code changes. It is solely to rectify the issue that the 2.13.0 release encountered during the release process, where the source jars were not created.
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.13.0...sshd-2.13.1
The 2.13.0 release notes are available at https://github.com/apache/mina-sshd/releases/tag/sshd-2.13.0
SSHD 2.13.0
- GH-318: Handle cascaded proxy jumps by @tomaswolf in #512
- GH-427: Read initial ACK on channel open prior to direct stream upload & close streams prior to exit code handling by @TerraNibble in #464
- GH-455: ensure BaseCipher.update() fulfills the contract by @tomaswolf in #463
- GH-470: Synchronize not thread safe java.security.KeyPairGenerator.generateKe… by @zakharovsergey1000 in #467
- GH-476: Fix Android detection false negative by @wh0
- GH-475: Switch uses of JSch library to the com.github.mwiede:jsch fork by @Alex-Vol-Amz
- GH-472: change client start condition in sshd-spring-sftp by @alwaystom
- GH-489: sftp readdir: determine file type from longname by @tomaswolf in #491
- GH-486: Add missing U2F {ed25519,ecdsa}-sk public key equality methods by @lf-
- SSHD-1237 Handle keep-alive channel requests by @tomaswolf in #492
- GH-494: Nio2Session improvements by @evgeny-pasynkov
- GH-468: Handle excess data in SFTP read requests by @tomaswolf in #495
- GH-498: Implement the "sntrup761x25519-sha512@openssh.com" KEX method by @tomaswolf
- GH-500: SftpFileSystemProvider: close SftpClient on exception by @tomaswolf in #501
- GH-504: Pass reason to sessionNegotiationEnd by @duco-lw in #505
- GH-461: Fix heartbeats with
wantReply=true
by @tomaswolf in #507 - GH-493: Fix arcfour128 and arcfour256 ciphers (regression in 2.2.0)
- GH-509: SFTP v[456] client: validate attribute flags
- GH-510: Fix class name in BuiltinIoServiceFactoryFactories (regression in 2.6.0)
The key exchange method sntrup761x25519-sha512@openssh.com is now available if the Bouncy Castle library is available.
This uses a post-quantum key encapsulation method (KEM) to make key exchange future-proof against quantum attacks. More information can be found in IETF Memo Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512.
GH-318 Handle cascaded proxy jumps
Proxy jumps can be configured via host configuration entries in two ways. First, proxies can be chained directly by specifiying several proxies in one ProxyJump
directive:
Host target
Hostname somewhere.example.org
User some_user
IdentityFile ~/.ssh/some_id
ProxyJump jumphost2, jumphost1
Host jumphost1
Hostname jumphost1@example.org
User jumphost1_user
IdentityFile ~/.ssh/id_jumphost1
Host jumphost2
Hostname jumphost2@example.org
User jumphost2_user
IdentityFile ~/.ssh/id_jumphost2
Connecting to server target
will first connect to jumphost1
, then tunnel through to jumphost2
, and finally tunnel to target
. So the full connection will be client
→jumphost1
→jumphost2
→target
.
Such proxy jump chains were already supported in Apache MINA SSHD.
Newly, Apache MINA SSHD also supports cascading proxy jumps, so a configuration like
Host target
Hostname somewhere.example.org
User some_user
IdentityFile ~/.ssh/some_id
ProxyJump jumphost2
Host jumphost1
Hostname jumphost1@example.org
User jumphost1_user
IdentityFile ~/.ssh/id_jumphost1
Host jumphost2
Hostname jumphost2@example.org
ProxyJump jumphost1
User jumphost2_user
IdentityFile ~/.ssh/id_jumphost2
also works now, and produces the same connection client
→jumphost1
→jumphost2
→target
.
It is possible to mis-configure such proxy jump cascades to have loops. (For instance, if host jumphost1
in the above example had a ProxyJump jumphost2
directive.) To catch such misconfigurations, Apache MINA SSHD imposes an upper limit on the total number of proxy jumps in a connection. An exception is thrown if there are more than CoreModuleProperties.MAX_PROXY_JUMPS
proxy jumps in a connection. The default value of this property is 10. Most real uses of proxy jumps will have one or maybe two proxy jumps only.
GH-461 Fix heartbeats with wantReply=true
The client-side heartbeat mechanism has been updated. Such heartbeats are configured via the CoreModuleProperties.HEARTBEAT_INTERVAL
property. If this interval is > 0, heartbeats are sent to the server.
Previously these heartbeats could also be configured with a CoreModuleProperties.HEARTBEAT_REPLY_WAIT
timeout. If the timeout was <= 0, the client would just send heartbeat requests without expecting any answers. If the timeout was > 0, the client would send requests with a flag indicating that the server should reply. The client would then wait for the specified duration for the reply and would terminate the connection if none was received.
This mechanism could cause trouble if the timeout was fairly long and the server was slow to respond. A timeout longer than the interval could also delay subsequent heartbeats.
The CoreModuleProperties.HEARTBEAT_REPLY_WAIT
property is now deprecated.
There is a new configuration property CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX
instead. It defines a limit for the number of heartbeats sent without receiving a reply before a session is terminated. If the value is <= 0, the client still sends heartbeats without expecting any reply. If the value is > 0, the client will request a reply from the server for each heartbeat message, and it will terminate the connection if the number of unanswered heartbeats reaches CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX
.
This new way to configure heartbeats aligns with the OpenSSH configuration options ServerAliveInterval
and ServerAliveCountMax
.
For compatibility with older configurations that explicitly define CoreModuleProperties.HEARTBEAT_REPLY_WAIT
, the new code maps this to the new configuration (but only if CoreModuleProperties.HEARTBEAT_INTERVAL
> 0 and the new property CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX
has not been set) by setting CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX
to
CoreModuleProperties.HEARTBEAT_REPLY_WAIT
<= 0:CoreModuleProperties.HEARTBEAT_NO_REPLY_MAX = 0
- otherwise:
(CoreModuleProperties.HEARTBEAT_REPLY_WAIT / CoreModuleProperties.HEARTBEAT_INTERVAL) + 1
.
GH-468 SFTP: validate length of data received: must not be more than requested
SFTP read operations now check the amount of data they get back. If it's more than requested an exception is thrown. SFTP servers must never return more data than the client requested, but it appears that there are some that do so. If property SftpModuleProperties.TOLERATE_EXCESS_DATA
is set to true
, a warning is logged and such excess data is silently discarded.
The AES-CBC ciphers aes128-cbc
, aes192-cbc
, and aes256-cbc
have been removed from the default list of cipher algorithms that a server proposes in the key exchange. OpenSSH has removed these cipher algorithms from the server proposal in 2014, and has removed them from the client proposal in 2017.
The cipher implementations still exist but they are not enabled by default. Existing code that explicitly sets the cipher factories is unaffected. Code that relies on the default settings will newly create a server that does not support the CBC-mode ciphers. To enable the CBC-mode ciphers, one can use for instance
SshServer server = ServerBuilder.builder()
...
.cipherFactories(BuiltinFactory.setUpFactories(false, BaseBuilder.DEFAULT_CIPHERS_PREFERENCES));
...
.build();
For the SSH client, the CBC ciphers are still enabled by default to facilitate connecting to legacy servers. We plan to remove the CBC ciphers from the client's defaults in the next release.
- @zakharovsergey1000 made their first contribution in https://github.com/apache/mina-sshd/pull/467
- @wh0 made their first contribution in https://github.com/apache/mina-sshd/pull/476
- @Alex-Vol-Amz made their first contribution in https://github.com/apache/mina-sshd/pull/475
- @alwaystom made their first contribution in https://github.com/apache/mina-sshd/pull/472
- @lf- made their first contribution in https://github.com/apache/mina-sshd/pull/486
- @TerraNibble made their first contribution in https://github.com/apache/mina-sshd/pull/464
- @duco-lw made their first contribution in https://github.com/apache/mina-sshd/pull/505
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.12.1...sshd-2.13.0
Apache MINA SSHD 2.12.1
- GH-458 Singleton thread pool for kex message handler flushing
- SSHD-1338 Restore binary compatibility with 2.9.2
- Fix link by @swiedenfeld in https://github.com/apache/mina-sshd/pull/454
- SSHD-1338 Restore binary compatibility with 2.9.2 by @gnodet in https://github.com/apache/mina-sshd/pull/456
- Use a singleton threadpool for kex message handler flushing by @FliegenKLATSCH in https://github.com/apache/mina-sshd/pull/459
- @swiedenfeld made their first contribution in https://github.com/apache/mina-sshd/pull/454
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.12.0...sshd-2.12.1
Apache MINA SSHD 2.12.0
- GH-428/GH-392 SCP client fails silently when error signalled due to missing file or lacking permissions
- GH-434 Ignore unknown key types from agent or in OpenSSH host keys extension
- GH-429 Support GIT protocol-v2
- GH-445 OpenSSH "strict key exchange" protocol extension (CVE-2023-48795 mitigation)
Following GH-428/GH-392 a new handleReceiveCommandAckInfo
method has been added to enable users to inspect acknowledgements of a receive
related command. The user is free to inspect the command that was attempted as well as the response code and decide how to handle it - including even throwing an exception if OK status (if this makes sense for whatever reason). The default implementation checks for ERROR code and throws an exception if so.
GH-445 implements an extension to the SSH protocol introduced in OpenSSH 9.6. This "strict key exchange" extension hardens the SSH key exchange against the "Terrapin attack" (CVE-2023-48795). The extension is active if both parties announce their support for it at the start of the initial key exchange. If only one party announces support, it is not activated to ensure compatibility with SSH implementations that do not implement it. Apache MINA sshd clients and servers always announce their support for strict key exchange.
- @evgeny-pasynkov made their first contribution in https://github.com/apache/mina-sshd/pull/424
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.11.0...sshd-2.12.0
Apache MINA SSHD 2.11.0
This new minor release provides a bunch of bug fixes and enhancements. This release is available for download from the Apache MINA SSHD website.
- GH-328 Added configurable timeout(s) to
DefaultSftpClient
- GH-370 Also compare file keys in
ModifiableFileWatcher
. - GH-371 Fix channel pool in
SftpFileSystem
. - GH-383 Use correct default
OpenOption
s inSftpFileSystemProvider.newFileChannel()
. - GH-384 Use correct lock modes for SFTP
FileChannel.lock()
. - GH-388
ScpClient
: support issuing commands to a server that uses a non-UTF-8 locale. - GH-398
SftpInputStreamAsync
: fix reporting EOF on zero-length reads. - GH-403 Work-around a bug in WS_FTP <= 12.9 SFTP clients.
- GH-407 (Regression in 2.10.0) SFTP performance fix: override
FilterOutputStream.write(byte[], int, int)
. - GH-410 Fix a race condition to ensure
SSH_MSG_CHANNEL_EOF
is always sent beforeSSH_MSG_CHANNEL_CLOSE
. - GH-414 Fix error handling while flushing queued packets at end of KEX.
- GH-420 Fix wrong log level on closing an
Nio2Session
. - SSHD-789 Fix detection of Android O/S from system properties.
- SSHD-1259 Consider all applicable host keys from the known_hosts files.
- SSHD-1310
SftpFileSystem
: do not close user session. - SSHD-1327
ChannelAsyncOutputStream
: remove write future when done. - SSHD-1332 (Regression in 2.10.0) Resolve ~ in IdentityFile file names in
HostConfigEntry
.
- SSHD-1330 Use
KeepAliveHandler
global request instance in client as well - GH-356 Publish snapshot maven artifacts to the Apache Snapshots maven repository.
- Bundle sshd-contrib has support classes for the HAProxy protocol V2.
Previous versions of Apache MINA sshd used SFTP file handles that were twice as large as configured via SftpModuleProperties.FILE_HANDLE_SIZE
. The reason for this was that the file handle bytes were stringified, representing each byte as two hex characters. This stringified file handle was then send over the wire. If SftpModuleProperties.FILE_HANDLE_SIZE
was configured as 16, the actual file handle size was thus 32 bytes.
This has been fixed in this version.
Additionally, the default setting for the size of file handles has been changed from 16 to 4 bytes. OpenSSH also uses 4-byte SFTP file handles. Using the same size not only means that there is a little more space left in SSH packets for actual data transfer, it also completely avoids the WS_FTP bug mentioned in GH-403.
Was previously only on server-side - now also for client (see SSHD-1330). This should be fully backward compatible since most servers do not send this request. However, if users have somehow added this handler to the client side independently, the code should be re-examined and the independent handler removed or make it replace the global one.
The aforementioned fix for the size of SFTP file handles has the potential to have undesired effects on existing server-side code that assumed that such SFTP file handles contained only printable characters. This is no longer the case. For historical reasons, Apache MINA sshd stores these SFTP file handles as Java String
s, and it's not possible to change this without breaking a lot of APIs. So this was kept, but the strings are now encoded as ISO-8859-1 and may contain arbitrary characters in the range from 0 to 255. This change should be transparent as SFTP file handles are supposed to be opaque, but there is one caveat:
If you have implemented your own server and have subclassed SftpSubsystem
or if you install an SftpEventListener
that stores or logs raw SFTP file handles, your code may need to be adapted. There is a new method String Handle.safe(String rawHandle)
that can be used to convert an SFTP file handle to a printable string.
Otherwise the change is transparent to server implementors and to SFTP clients. (On the client side, Apache MINA sshd already used byte[]
to represent SFTP file handles.)
As part of the fix for GH-371 the channel pool in SftpFileSystem
was rewritten completely. Previous code also used ThreadLocal
s to store SftpClient
s, which could cause memory leaks.
These ThreadLocal
s have been removed, and the channel pool has been rewritten to function similar to a Java ThreadPool
: the pool has a maximum size; it has an expiration duration after which an idle channel is removed and closed, and it has a "core size" of channels to keep even if they are idle. If a channel is closed for any reason it is evicted from the pool.
Properties to configure these pool parameters have been added to SftpModuleProperties
.
- @hannibal218bc made their first contribution in https://github.com/apache/mina-sshd/pull/372
- @fherbreteau made their first contribution in https://github.com/apache/mina-sshd/pull/404
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.10.0...sshd-2.11.0
Apache Mina SSHD 2.9.3
Apache Mina SSHD 2.9.3 is a bug fix release. This release is available for download from the Apache MINA SSHD website.
- CVE-2023-35887 / SSHD-1324 Rooted file system can leak informations
- Fix reproducible builds issue
- Support building with Maven 3.9.x
Full Changelog: https://github.com/apache/mina-sshd/compare/sshd-2.9.2...sshd-2.9.3