GH-318 Handle cascaded proxy jumps
GH-427 SCP client: fix DefaultScpClient.upload(InputStream, ...)
GH-455 Fix BaseCipher: make sure all bytes are processed
GH-461 Fix heartbeats with wantReply=true
GH-470 MontgomeryCurve: synchronize access to KeyPairGenerator
GH-489 SFTP v3 client: better file type determination
GH-493 Fix arcfour128 and arcfour256 ciphers (regression in 2.2.0)
GH-500 SFTP file system: fix memory leak on exceptions
GH-504 Pass through failure exception to SessionListener.sessionNegotiationEnd()
GH-509 SFTP v[456] client: validate attribute flags
GH-510 Fix class name in BuiltinIoServiceFactoryFactories (regression in 2.6.0)
PR-472 sshd-spring-sftp: fix client start
PR-476 Fix Android detection
PR-486 Add missing equals and hashCode to U2F key classes
SSHD-1237 Handle keep-alive channel requests
sntrup761x25519-sha512@openssh.com Key ExchangeThe 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.
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.
wantReply=trueThe 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(CoreModuleProperties.HEARTBEAT_REPLY_WAIT / CoreModuleProperties.HEARTBEAT_INTERVAL) + 1.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.