# Could not load a dependent class com/jcraft/jsch/Logger

Have you ever seen an Ant error message like this?

BUILD FAILED
/Users/elharo/Projects/XOM/build.xml:545: Problem: failed to create task or type scp
Cause: Could not load a dependent class com/jcraft/jsch/Logger
It is not enough to have Ant's optional JARs
you need the JAR files that the optional tasks depend upon.
Ant's optional task dependencies are listed in the manual.
Action: Determine what extra JAR files are needed, and place them in one of:
-/opt/ant/lib
-/Users/elharo/.ant/lib
-a directory added on the command line with the -lib argument

Do not panic, this is a common problem.
The commonest cause is a missing JAR.

This is not a bug; it is a configuration problem

As usual, the ant error message is completely unhelpful, though for once it’s at least technically correct. (Most of the time when ant says, “This is not a bug; it is a configuration problem”, it is in fact a bug and not a configuration problem.) Here’s what’s really happening.

The jsch jar file distributed from http://www.jcraft.com/jsch/ is corrupt. Either they uploaded it wrong or they misconfigured their web server or both. (Update: it looks like a misconfigured server/poorly designed web page. The so-called download link isn’t that at all. You can follow it but not save it.) The jar file with the relevant classes is there, but it’s no good. You can check your local copy by trying to list its contents with
jar tvf

:

\$ jar tvf /usr/share/ant/lib/jsch*jar
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.zip.ZipFile.(ZipFile.java:75)
at sun.tools.jar.Main.list(Main.java:979)
at sun.tools.jar.Main.run(Main.java:224)
at sun.tools.jar.Main.main(Main.java:1149)

If you see anything but a list of classes, the problem is that the JSCH jar is no good. To fix it, use this link to sourceforge instead.

Once again I am reminded of the perils of depending on external libraries, especially ones you don’t build or distribute with your own product. In 2010 ssh and scp are mandatory features of any build and deployment system. Secure communications are too important to be left to random third party web sites.

### 2 Responses to “Could not load a dependent class com/jcraft/jsch/Logger”

1. Jonathan Doughty Says:

Yet the message I am getting from this is that someone downloaded a Java implementation of SSH and did not check the signatures of the binary before dropping it into their Ant configuration and attempting to use it. Yikes. Or did not get highly suspicious when the signatures (a mere MD5) did match on file that later turned out to be a corrupted file.

Then it looks like someone merrily started to build a distribution of another library that was going to be made publicly available using that unchecked binary distribution of supposedly secure communication software.

I wish I read Japanese so I could appreciate JSch’s “Man-in-the-Middle Attack for SSH with Scala and JSch.” As a minimum everyone needs to read Thompson’s Reflections on Trusting Trust.

2. Elliotte Rusty Harold Says:

Valid points, though not just someone. Pretty much everyone.

We need to face the fact that the whole signature verification effort is fundamentally flawed, not algorithmically but in UI. In practice, signature verification simply doesn’t work on the Web.

In this case, verifying the signature might have revealed a corrupted file. However it would not (and still does not) prove the authenticity of the archive because there’s no trusted signature to verify. The web page from JCraft says the signature is 74ea920580077b4c0b51101a8292a529 but that signature itself is served over http, so who’s to say a man in the middle hasn’t changed that page? And who’s JCraft anyway? Why should I trust them? Or everyone with committer rights to the Ant project?

It may be possible to use digital signatures within a well-run, tightly managed Intranet to verify locally distributed software and web pages. Digital signatures alone wouldn’t be enough. You’d also need to centrally control what software and signatures can be installed and run on individual computers. I doubt it’s possible to manage and verify signatures at Internet scale though.