Copy link to clipboard
Copied
We are setting up an SFTP connection via cfftp, and are currently receiving the following error:
"Error: Session.connect: java.io.IOException: End of IO Stream Read."
We have narrowed it down to the version of JSch, which is currently jsch-0.1.54. This will work if we use diffie-hellman-group-exchange-sha1 algorithm, but we need to use diffie-hellman-group-exchange-sha256, which produces the above error. Testing this outside of CF, we have managed to prove that it works successfully using jsch-0.1.55, while returning the same error above using jsch-0.1.54.
So we have been trying to update the CF FTP package to jsch-0.1.55, using the approach detailed here:
https://helpx.adobe.com/nz/coldfusion/kb/apply-custom-patch-coldfusion-2021.html
Which somewhat usefully has this exact update as it's example. It installs without issue (and we can see the dependency shown as jsch-0.1.55 in the FTP package in the administrator), but it still continues to pick up the jsch-0.1.54 library instead. We have tried removing this and tempoarily uninstalling the other packages that also list jsch-0.1.54 as a dependency (e.g. ZIP), purging cache, multiple CF service restarts etc, but have not had any luck in getting it to actually use jsch-0.1.55 instead.
I also tried to load it directly via javasettings/loadpaths (specifying a local dir where I had the jsch-0.1.55.jar), but no luck with that either.
Any pointers or suggestions as to where we are going wrong would be much appreciated.
Copy link to clipboard
Copied
I have a question on the JSON used in the example you've referenced. Did you change the setting "2021.0.0.324000" to the latest value, say, "2021.0.05.330109"?
Copy link to clipboard
Copied
Thanks for the response.
Yes, I can confirm we did change that to 2021.0.05.330109 in the JSON patch.
We have also tried using "this.javaSettings" to point to a copy of the jsch-0.1.55 JAR in a custom directory. And even installed the old javaloader library to try to load the specific file path directly.
All are still resulting in dumping the "com.jcraft.jsch.JSch" object showing "java.lang.String VERSION: 0.1.54".
Copy link to clipboard
Copied
I think that it is not enough to change only the FTP settings. In other words, I think that Adobe's example in
https://helpx.adobe.com/nz/coldfusion/kb/apply-custom-patch-coldfusion-2021.html
is incomplete.
To see what I mean, open \bundles\bundlesdependency.json in a text editor and search for jsch. You will see that the Jsch JAR is needed by both the FTP and ZIP packages. However, the Adobe example considered only the FTP case.
In any case, the process that Adobe describes may be flawed in another way. From what you describe, it is apparent that the JSCH version is tightly coupled to the FTP version. The JAR of the current FTP bundle is ftp-2021.0.05.330109.jar. So whenever you run cfpm/install ftp or cfpm/install ftp:2021.0.05.330109 the JSCH version is automatically re-instated to 0.1.54. To change to jsch 0.1.55, you will need either a different ColdFusion build number or a different FTP bundle version number.
Copy link to clipboard
Copied
On second thoughts, I would suggest you contact Adobe Support (cfsup[at]adobe.com) about that example.
Copy link to clipboard
Copied
We're having a similar SFTP issue with CFFTP, but with Error: Algorithm negotiation fail.
Were you able to update the JSch version CF uses? Any tips would be great thanks.
Copy link to clipboard
Copied
No, no luck unfortunately - Adobe just requested I raise a bug report for it. Which is here:
https://tracker.adobe.com/#/view/CF-4217813
If you are playing around with it, be aware that the jsch-1.55 library itself has a bug in it, that displays it's version number as jsch-1.54 (so even if you get it pointing at the correct library, a CFDUMP will still show you are using jsch-1.54). We edited the library to fix that bug, but still had no luck - even editing the files, re-applying and re-starting the libraries in CF just points it back and applies the default 1.54 library again.
We had to instead use Java calls directly to connect to sFTP, which worked - I included the examples in the bug report, so that may work for you as an alternative.
Copy link to clipboard
Copied
Thanks very much, that's very helpful info.