Plan SSHD 3.0

[gnodet]

Description

SSHD could raise the target JDK runtime to JDK 17 or more.

Motivation

This would allow raising some dependencies:
https://github.com/apache/mina-sshd/blob/master/.github/dependabot.yml#L25-L47

Alternatives considered

With the new JDK release train, libraries and projects have to move along in order to not be kept back on old unsupported dependencies.

Additional context

No response

[tomaswolf]

For 3.0.0, I have quite a few things that I'd like to do:

• Break API big style :-) Seriously. There are a things in the list below that just cannot be done without breaking API.
• Undo that awful sshd-common/sshd-core split. Instead, have sshd-common/sshd-client/sshd-server, without split packages. Make then all three proper OSGi bundles, and drop the sshd-osgi re-amalgamation.
• A similar split might make sense on SFTP level (sshd-sftp-common/sshd-sftp-client/sshd-sftp-server).
• Change the session initialization. Sessions should not initiate communication in their constructor! Have an explicit start() method instead, and make sure it's called at an appropriate time.
• Have a mechanism to configure a session after it has been instantiated, but before it starts. (Other than global properties on the SshClient!) There needs to be a simple way to configure sessions individually right after they have been created.
• Refactor the SSH protocol implementation. It's a mess IMO, split over various levels of inheritance, which just feels wrong. Use composition instead. Give each session a filter chain. Implement the transport layer as a filter in that filter chain. Implement the authentication protocol as a filter atop. Implement the connection protocol atop. A callback from transportation layer to connection layer will be needed to handle getting "unsupported" replies (transport layer) to unknown global requests (connection layer).
• Implement client-side proxy protocol (SOCKS, HTTP CONNECT) as a filter that can be inserted beneath the transport layer filter.
• Don't require Bouncy Castle for EC keys. Java has built-in support for these even in Java 8.
• Don't require net.i2p for ed25519/curve25519. It has a security flaw. Make our code work with any of Java ed25519 (since Java 15), BC ed25519, or net.i2p. (Tried already, but it's messy, and not possible without API breaks. Now that we require Java 17 for building, it would be easier to do.)
• Have multi-release JARs (especially for the cipher algorithms and ed25519)
• Rethink whether all the machinery for SecurityRegistrars is really needed and worth the maintenance effort. Can't we just use whatever Security providers are installed, and leave it at that? All that dynamic class loading is so fragile, and it might not always use the appropriate class loaders... (see e.g. GH issue 502)

Plus umpteen little details changes that I can't enumerate all right now.

Some of these ideas might need to be written down in more detail first. Do we have a wiki somewhere? (Confluence? GH wiki pages? Or collaborate in a Google doc?)

[tomaswolf]

One more thing:

• Pass on the HostConfigEntry to the created session. It needs access to it for various advanced configs (like AddKeysToAgent, to mention just one).

[lgoldstein]

Note that setting the target to JDK 17 would greatly restrict the Android compatibility (maybe even making it impossible). I am not sure how widespread the use of SSHD is for Android devices, so it is difficult to estimate the impact of such a decision. I am not against this move, just pointing out that any decision should take this issue into account.