Affected version
3.5.3 and every earlier release, plus master.
Description
wagon-ssh depends on com.jcraft:jsch:0.1.55, last released on 2018-11-26, and on com.jcraft:jsch.agentproxy.*:0.0.9 from 2014. Neither has a maintainer. This is not only a hygiene problem — the provider is already broken against current servers and current keys:
- 0.1.55 implements neither
rsa-sha2-256 nor rsa-sha2-512, so RSA public key authentication fails against OpenSSH 8.8 and later, which stopped accepting ssh-rsa (SHA-1) signatures by default in 2021.
- 0.1.55 cannot read the OpenSSH-v1 private key format, which
ssh-keygen has emitted by default since OpenSSH 7.8 in 2018.
So a user generating a key today, on a server released any time in the last four years, cannot authenticate with it.
Proposal
Move to com.github.mwiede:jsch, the maintained fork, currently 2.28.6 (2026-07-29). This is what #680 asked for in 2021, from the fork's own author. Recording the evaluation here so the decision has the details in one place.
Why the fork rather than a different library
- It keeps the
com.jcraft.jsch package and the same API. Every type this provider uses is present: JSch, Session, ChannelExec, ChannelSftp, SftpATTRS, UserInfo, UIKeyboardInteractive, HostKey, HostKeyRepository, IdentityRepository, ProxyHTTP, ProxySOCKS5.
- Its base bytecode is Java 8, so it fits the 3.x baseline.
- The JSch coupling here is 7 files and about 1565 lines, all under
wagon-ssh/.../providers/ssh/jsch/. wagon-ssh-common refers to com.jcraft.jsch.UserInfo only in a javadoc @see, so the shared module has no compile dependency on it.
Apache MINA SSHD was considered and does not fit today. It would be the natural choice inside the foundation, and it is already a test dependency of wagon-ssh-common-test. But AbstractJschWagon supports connecting through HTTP and SOCKS5 proxies, and MINA SSHD 2.x has no client-side connect-through-proxy — apache/mina-sshd#481, with a fix deferred to the 3.0 filter chain. Porting onto 2.x would silently drop that for the corporate users most likely to still be deploying over scp. Worth revisiting when 3.0 lands.
sshj was not pursued: it costs a full port like MINA and adds a mandatory BouncyCastle dependency.
Licensing is not a concern: the fork keeps JSch's BSD/ISC terms, which are ASF Category A. Apache Camel (CAMEL-17835) and Apache Commons VFS (VFS-837) have both already made this switch.
What the change involves
Not quite a coordinate swap. The com.jcraft.jsch.agentproxy.* types the provider imports — ConnectorFactory, Connector, RemoteIdentityRepository — have no counterpart in the fork, which integrates the agent as SSHAgentConnector, AgentConnector and AgentIdentityRepository. That is roughly fifteen lines in AbstractJschWagon, and the two jsch.agentproxy artifacts go away.
Behaviour changes to put in the release notes
- The fork disables
ssh-rsa (SHA-1) by default. Deploying to an old server or appliance that offers nothing newer needs jsch.server_host_key and jsch.client_pubkey set. Both replace the list wholesale, so name every algorithm to keep, not just the one to add — -Djsch.server_host_key=ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa. The OpenSSH +/- prefix syntax is not accepted by these properties; it works only in a config file read through OpenSSHConfig.
- Ed25519 keys need Java 15+ at runtime, or BouncyCastle on the classpath.
- Reaching the SSH agent uses a Unix domain socket, which the JDK provides from Java 16. Below that it depends on a helper library being present.
- Host key type negotiation order differs, so a host whose
known_hosts entry is an old ssh-rsa key may need re-accepting.
Related
Verification before release
The -Dssh-tests profile is excluded by default and should be run for this. Those tests use the embedded MINA server and exercise the host key error paths, which match on JSch's exception message text — the one place a library swap could break something quietly.
Affected version
3.5.3 and every earlier release, plus
master.Description
wagon-sshdepends oncom.jcraft:jsch:0.1.55, last released on 2018-11-26, and oncom.jcraft:jsch.agentproxy.*:0.0.9from 2014. Neither has a maintainer. This is not only a hygiene problem — the provider is already broken against current servers and current keys:rsa-sha2-256norrsa-sha2-512, so RSA public key authentication fails against OpenSSH 8.8 and later, which stopped acceptingssh-rsa(SHA-1) signatures by default in 2021.ssh-keygenhas emitted by default since OpenSSH 7.8 in 2018.So a user generating a key today, on a server released any time in the last four years, cannot authenticate with it.
Proposal
Move to
com.github.mwiede:jsch, the maintained fork, currently 2.28.6 (2026-07-29). This is what #680 asked for in 2021, from the fork's own author. Recording the evaluation here so the decision has the details in one place.Why the fork rather than a different library
com.jcraft.jschpackage and the same API. Every type this provider uses is present:JSch,Session,ChannelExec,ChannelSftp,SftpATTRS,UserInfo,UIKeyboardInteractive,HostKey,HostKeyRepository,IdentityRepository,ProxyHTTP,ProxySOCKS5.wagon-ssh/.../providers/ssh/jsch/.wagon-ssh-commonrefers tocom.jcraft.jsch.UserInfoonly in a javadoc@see, so the shared module has no compile dependency on it.Apache MINA SSHD was considered and does not fit today. It would be the natural choice inside the foundation, and it is already a test dependency of
wagon-ssh-common-test. ButAbstractJschWagonsupports connecting through HTTP and SOCKS5 proxies, and MINA SSHD 2.x has no client-side connect-through-proxy — apache/mina-sshd#481, with a fix deferred to the 3.0 filter chain. Porting onto 2.x would silently drop that for the corporate users most likely to still be deploying over scp. Worth revisiting when 3.0 lands.sshjwas not pursued: it costs a full port like MINA and adds a mandatory BouncyCastle dependency.Licensing is not a concern: the fork keeps JSch's BSD/ISC terms, which are ASF Category A. Apache Camel (CAMEL-17835) and Apache Commons VFS (VFS-837) have both already made this switch.
What the change involves
Not quite a coordinate swap. The
com.jcraft.jsch.agentproxy.*types the provider imports —ConnectorFactory,Connector,RemoteIdentityRepository— have no counterpart in the fork, which integrates the agent asSSHAgentConnector,AgentConnectorandAgentIdentityRepository. That is roughly fifteen lines inAbstractJschWagon, and the twojsch.agentproxyartifacts go away.Behaviour changes to put in the release notes
ssh-rsa(SHA-1) by default. Deploying to an old server or appliance that offers nothing newer needsjsch.server_host_keyandjsch.client_pubkeyset. Both replace the list wholesale, so name every algorithm to keep, not just the one to add —-Djsch.server_host_key=ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa. The OpenSSH+/-prefix syntax is not accepted by these properties; it works only in a config file read throughOpenSSHConfig.known_hostsentry is an oldssh-rsakey may need re-accepting.Related
Verification before release
The
-Dssh-testsprofile is excluded by default and should be run for this. Those tests use the embedded MINA server and exercise the host key error paths, which match on JSch's exception message text — the one place a library swap could break something quietly.