About JSch open source project

There are many, many open source, pure java implementation for the SSH/SFTP protocol. However, in my opinion, there are two of them that can be taken seriously. One of them is JSch, the other one is Trilead SSH. I will talk about my experience on the former one while implementing the RemoteTools framework for the Parallel Tools Platform for Eclipse.

JSch is one of the few (if not the only one) open source, pure Java implementation with the a complete implementation of the SSH specification, covering both SSH versions. It also covers less common ssh use cases, like High Performance Enabled SSH/SCP (although I have not yet seen a SSH server willing to easily support this). The JSch maintainers are very careful to adhere strictly to the ssh specification. They even refuse to implement workarounds for known issues for common ssh servers. They reply: “Ask your ssh server provider for a fix”. And I tend to agree with them.

And JSch works with good performance, although written in pure Java and though spawning a large number of Java threads (probably, there would be better performance by spawing only one thread).

Other interesting point of JSch is its very flexible license. It is not surprising that the maintainers have chosen the Eclipse Public License, since they conveniently decided to cooperate with the Eclipse foundation to have JSch distributed by default with all Eclipse framework distributions. Therefore, many IBM Eclipse based products take advantage of JSch and its business friendly license.

Releases and bugfixes are frequent and the maintainers respond within short time to people reporting bugs and issues. The JSch library has become more and more stable.

The developer will notice that JSch provides a very low level library for the SSH protocol. It fits like a glove for the programmer who wants to have full control over the SSH connection. However, a lot of coding is required even for trivial tasks, like running a simple command on the remote host. The programmer has to take care of every minimal detail. Well, these are the classic pros/cons of a low level library.

JSch maintainers took the sentence “the source is the documentation” to the extreme. There is absolutely no comment in the code. There is no documentation of the APIs of the library. No, the API is very counterintuitive and does not follow any design to be expected. Once you have unzipped the source, you are one your own. Yes, at least, there are some examples.

But once you know all SSH specification documents by hard, JSch starts looking easier. The JSch library is very close to the specification. Classes match exactly entities described in the SSH specification. So do methods, that are named exactly as the operations from the specification. This is also true for parameters, return values, constants and exceptions.

After reading the JSch code, I can state that the maintainers really do not like Java. The code, although written in Java, looks like old style C. Jsch does not follow Java coding conventions. I wonder how JSch was accepted on the Eclipse community, considering its rigorous development conventions. Curiously, all code is written in “emacs”. I really cannot understand this. Why? If they developed JSch for the most powerful and complete Java IDE.

Furthermore, the maintainers do not feel like employing design patterns. Many issues arise on the design of the API. The poor class hierarchy prevents the programmer from writing good quality code while handling JSch objects. Visibility of methods is difficult to be understand, specially because they are only meaningful at certain points of the class hierarchy, but always visible and accessible.

Specially, the approach Jsch uses for authentication is completely misunderstood. Nobody can explain the purpose of all the methods in class that needs to implement to provide authentication information.
Even worse, the methods of this class are intended for interactions with user through GUI.

Unfortunately, the maintainers do not seem to like the open source community. Suggestions to improve JSch are redirected to /dev/null. People willing to help are discouraged by the maintainers. Contributions are silently ignored. Many good ideas and important improvements were lost due the egoism of the maintainers.

The JSch project does not use common open source tools, like bugzilla, wiki or forum. Although the bugzilla and forum are open for the community, they are never read by the maintainers. All communication is done through a strange mailing list with no useful feature (even searching for messages is not possible).

Error handling needs urgent improvement. The only approach for the application to recover from errors is parsing the message inside the exception, a very poor programming practice in Java. For example, this issue is very serious, because once the connection fails to establish, it is not possible to distinguish an unreachable host from invalid authentication.


JSch cannot be called “Open Source”, since the maintainer do not interact with the community. However, it has a great value of being the only implementation that follows strictly the SSH specification with a complete set of features.

16 Responses to About JSch open source project

  1. Senthil Kumar says:

    I tried to use the Jsch API for SSH, but It is very very hard to understand the API since there ZERO documentation available. I think good effort like this should be made usable otherwise I dont see any need for putting this much effort on developing this and making it open source……I spent time lot of time to look into this API…finally I got only lot of issues which cant be fixed with out a documentation…

  2. Konstantin says:

    JSch have very, VERY BAD source code…


    loooooooooooooooooong piece of code
    catch(Esception e){


    There is NO normal logging, NO correct debugging information. I was mad about understand “What’s wrong in my code? WTF IT’S NOT WORKING”.

    Strongly NOT RECOMMENDED this library.

    (Sorry russian man for my bad english)

    Regards, Konst.

  3. Martijn Verburg says:

    Couldn’t agree more with this post! We’ve managed to get Jsch working as the base implementation for our Open Source SFTP JCA connector, but boy it took some doing! The documentation is indeed non existent and the source code is really poor from a Java viewpoint.

    That said, it does what it says on the tin.

  4. quaid says:

    What about Trilead?

  5. Boris says:

    We use Jsch for communication with Linux and AIX hosts and also for transfering files from/to these hosts.

    With the examples it was easy to implement the functions we need.

    We suffer from a strange null pointer exception from time to time but we cant track it down.

    And – yes, documentation is non existent, format of code is bad and yes, its a example of c-guy-progamming-java.

    But all in all its ok for us.

  6. mimmo says:

    What’s the alternative for java dev over ssh ?

  7. Jan Peter Stotz says:

    If the author is uncooperative there is still the possibility to branch the project creating an own project (e.g. OpenJSch?) under the same license which allows to participate for improving the sources and creating a useful documentation.

  8. Martijn Verburg says:

    Yes I believe that is possible. I’ve had a few informal discussions with other developers about this but at the end of the day I’m involved in too many other OS projects to make this fly.

  9. Pingback: Pencils down | (((just another) just another) … just another) blog

  10. Rory says:

    Actually there is now a better alternative: it is still in alpha, but the GSoC project to add SSH / SCP support to the existing Commons-Net library is available for testing. The URL Is here:


    The code quality is much better than JSch. It will be slated for a release as soon as we can get some testers to run through it for a little bit :-)

  11. Jyotiman says:

    Can any body let me know if its possible to use Trilead to communicate with IBM AIX ?

    Thanks in advance for all your help and support

  12. Paul Reilly says:

    This is definitely a sad post and a confirming post. It captures my experience with JSch to a tee. How very distressing. And commons-net-ssh looks a tad immature at this point. Once there is Maven support for commons-net-ssh and an API I’ll probably become a user and supporter. For now I will set up to fork JSch with the goal of just having it be a stop-gap until something better comes along. By all means reply with any interest in supporting the fork as I’ll check back in a few months when and if I decide to make the fork public.

  13. Pingback: Death of the Euro

  14. scott2449 says:

    https://github.com/vngx/vngx-jsch fixes many of the issues and is true open source. Feel free to submit a pull request anytime

  15. Ashish Dugar says:

    I was able to login through JSCH into server. But when I hit /usr/sesu/bin command It needs a password and I was unable to send password through JSCH.Any help

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: