With the release notes of openssh 8.3 it is clear, that some day in the future, servers will not accept the ssh-rsa signature algorithm any more. It will be disabled by default, because the risk is too high, that people spend money for attacks to break it. Instead, rsa-sha2-256 or rsa-sha2-512 should be used, amongst others.
At the moment, some people ask about the Jsch library, a popular java SSH implementation, because it’s furture is unclear. Unfortunately there is no answer on the sourceforge mailing list and I also tried to reach out to jcraft, it’s original author, via email but did not receive an answer yet.
Because of the popularity of Jsch, I think a lot of people will be interested in new features and additional signature algorithms being released, because without support, they cannot use the current version 0.1.55 from November 2018 any more. When servers will not accept ssh-rsa any more and no alternative host keys are set up, connections will not work any more!
Then the question is, whether Jcraft will continue to maintain it, whether some fork will take it over or that projects will have to switch to other libraries, which are maintained more actively (like sshj). But do you want to spend the time and effort to switch to a new API if you can avoid it?
Speaking about forks. When I was looking for a ssh library to support forwarding unix sockets, I did not find it. Then I decided for Jsch, because I knew the API from previous projects and just implemented it myself. But after looking at the inactivity on the sourceforge platform, I decided to create a fork of Jsch on Github. And after receiving pull requests about more supported algorithms, I realized, what was going on and what it means for the future. And that is why I am writing this post actually.
When I was searching for a fork to contribute to, I did not find a useful one for Jsch. There is https://github.com/vngx/vngx-jsch which improved javadoc amongst other things, but at least this was released to maven central 8 years back. All other projects (https://github.com/gaoxingliang/JSch or https://github.com/is/jsch), that contain the sourcecode of Jsch, did not publish the code in the form, that others can embed it into their projects. Now the question is: Did they not publish it because of legal rights or the license? As far as I understand, the BSD license allows publishing it as long as you keep the original copyright notices within the artifact.
So finally my goal of setting up a fork was to make it useful to the community. And this is by releasing it to maven central. Please check https://github.com/mwiede/jsch for the latest released version.
The benefits of having this setup are the following:
- everybody can use it right away by setting up the artifact with maven or gradle or kotlin.
- drop-in replacement: because the code and the artifact are forks, the package name, the inner class names and the API remain the same.
- open for contribution, because it is hosted on GitHub. I think most of the people are used to Git nowerdays, so contribution on sourceforge is not attractive.
- upstream compatible: in the case, that Jcraft will jump in again and will continue to provide maintenance and releases, it will be easy to give it back in their hands.
So let’s see, how fast openssh will continue with its announced plans to disable ssh-rsa in the near future.
Recommendation If you are a user of Jsch, please have a look at your servers, and if in doubt, switch your maven or gradle coordinates to the releases of the fork I created.
Maven users, replace
<dependency> <groupId>com.jcraft</groupId> <artifactId>jsch</artifactId> <version>0.1.55</version> </dependency>
<dependency> <groupId>com.github.mwiede</groupId> <artifactId>jsch</artifactId> <version>0.1.58</version> </dependency>
Gradle users, replace
5 thoughts on “the future of jsch without ssh-rsa”
thanks for updating and maintaining the jsch fork!
Thank you for starting and maintaining this fork!
MGit (android git client) will be moving to use your fork in its next release.
Yes big thank you for maintaining this. Jedit wouldn’t open remote files anymore because of a bug in this library and your branch fixed it.
Thank you so much for creating and maintaining this library. I encountered the issue you described and your drop-in replacement perfectly addressed it.
I just want to keep the positive comments coming, I’m moving a deploy and want to use pure scala (currently in ammonite with tons of shell outs), and this is going to be a life saver. Thank you!