Can't connect to azure blob storage using jsch #115
Comments
|
Hi @ihudedi, What version of JSch produced this backtrace? Because I am a bit confused by parts of the stacktrace you provided above: In the 0.1.72 release, the line numbers above do not match the methods (lines 351 & 607 are not part of the Thanks, |
|
Hi @norrisjeremy |
|
Hi @ihudedi, Ok, thanks, that helps understand where the failure is happening. Would it be possible for you to run From the stack trace you provided above, JSch is failing immediately after it sends the initial KEXINIT and tries to read the KEXINIT response packet from the Azure server, which is a bit unusual. Also, does this exception consistently happen every time you connect, or is it an intermittent issue? Also, if possible, it may help if you could create a JSch Logger and capture JSch logging details (by creating a class that implements Thanks, |
|
Hi @ihudedi, Also, do you use a custom Thanks, |
|
Or any sort of |
|
Hi @norrisjeremy |
|
Hi @ihudedi, The problem appears to be due to a Palo Alto firewall between you and Azure that is prematurely closing the SSH connection: This Stackoverflow post has more details. Thanks, |
|
Hi @norrisjeremy [ihudedi.IL-ihudedi-W3] ➤ sftp -vvv sftpdatalakegen2.blob.core.windows.net I did the test from wrong machine. |
|
Hi @norrisjeremy |
|
Hi @ihudedi, As I mentioned earlier, based upon the stacktrace you provided as well as the earlier sftp trace, it appears that there is a Palo Alto Networks firewall that sits somewhere on the network between your JSch application is hosted and Azure that is prematurely closing the TCP connection between your application and Azure. To correct this, you will need to speak with your network/security administrators who manage this Palo Alto Networks firewall and adjust the policies on it to allow your application to connect to Azure. Thanks, |
|
Hi @norrisjeremy |
|
Hi @ihudedi, Ok, I have tested locally and confirmed the behavior. It seems that Azure performs some sort of filtering based upon the local SSH client string that is sent. For example, I see this: But if I manually patch the client string in Session.java from this: To this (to simulate OpenSSH's client string): With this manual change, the connection progresses as normal (the auth fails are because I don't have an actual account on Azure): Do you have a way to contact Microsoft and ask them about their service operates and why it is closes TCP connections for the JSch client string? We would also look into adding a new method to allow you to override the client string that JSch sends, so that you could override it to something that Azure would accept. Thanks, |
|
Hi @ihudedi, Ok, I think I've identified the issue. The problem is that Azure performs strict filtering of the client version string according to RFC 4253 section 4.2. The default client string we use for the "softwareversion" part ( I will work on a patch to change this to the underscore ( In the meantime, you should be able to work around the problem by using the Thanks, |
…ncluding minus sign characters mwiede#115.
|
Hi @norrisjeremy |
|
Hi @norrisjeremy |
|
@ihudedi this repo is a fork of JSch 0.1.55, which hasn't received any updates or bug fixes in years. This fix is part of version 0.2.0: https://github.com/mwiede/jsch/releases/tag/jsch-0.2.0 |
Hi,
When trying to connect azure blob storage via jsch(0.1.72) I am getting the following error:
com.jcraft.jsch.JSchException: Session.connect: java.io.IOException: End of IO Stream Read
at com.jcraft.jsch.Session.connect(Session.java:607)
at com.jcraft.jsch.Session.connect(Session.java:218)
at toolbox.sftp.Sftp.main(Sftp.java:319)
Caused by: java.io.IOException: End of IO Stream Read
at com.jcraft.jsch.IO.getByte(IO.java:85)
at com.jcraft.jsch.Session.read(Session.java:1246)
at com.jcraft.jsch.Session.connect(Session.java:351)
... 2 more
See documetation in https://docs.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support
Thanks,
Itay
The text was updated successfully, but these errors were encountered: