Connection to Azure SFTP doesnt work using JSCH

Question

Hello everyone,

we are currently working with a cloud product that uses JSCH internally to connect to external sftp sources. Im investigating an connection reset exception that we are getting when trying to connect to azure sftp.

Using wireshark i determined that the problem occurs after jsch initializes the client: key exchange. Establishing the same connection with filezilla we dont have this issue.
comparing the packages from jsch and filezilla i didn't see an obivious issues, jsch has azure supported algorithms in the key exchange request at least it looks like it to me but im not an expert on the ssh protocol. Im gonna post both requests below if somebody could give me any pointers it would be greatly appreciated.

jsch request that leads to azure closing the connection:

filezilla request that works:

jsch log output:

INFO: Connecting to ***** port 22  
INFO: Connection established  
INFO: Remote version string: SSH-2.0-AzureSSH_1.0.0  
INFO: Local version string: SSH-2.0-JSCH-0.1.54  
INFO: CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256  
INFO: CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521  
INFO: CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521  
INFO: SSH_MSG_KEXINIT sent  
INFO: Disconnecting from **** port 22  
com.jcraft.jsch.JSchException: Session.connect: java.net.SocketException: Connection reset  

Answer 1

@Brandl, Fabian Firstly, apologies for the delay in responding here and any inconvenience this issue may have caused.

I see you have posted the similar thread in SO forum, Please refer to the suggestions mentioned over-there and let me know if the issue still persist. I would like to work closer on this issue

Looking forward for your reply!

----------

Please do not forget to and wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

We are having the same problem. What I am assuming is when JSCH sends the Key Exchange Init it is NOT adding the optional guess as to what encryption, MAC and compression to use. When the AzureSSH does not see the guess, it has some type of problem or does not like that there is no guess and a TCP-RST is sent to terminate the connection.

I'm not sure why JSCH is not sending a guess, as we have done packet captures and it does for other SSH servers. I can only assume that most SSH client may have some lookup table for various SSH servers and sends a guess based on the SSH server it's taking to. JSCH has no knowledge of AzureSSH and instead of choosing some base guess, it chooses not to send a guess.

Not sending a guess is valid and when a guess is not sent, normal negotiation should take place.

We have been working with our vendor that uses JSCH and they don't know how to force JSCH to make a guess.

Answer 3

Hopefully MS sees this.

Looking at the capture I also noticed that that JSCH 0.1.54 has another issue, it uses just LF (0x0A) to terminate the identifier string, not CRLF (0x0D 0x0A) as the RFC documents you MUST use.

We have been in contact with our vendor and I think they said that JSCH 0.1.72 can connect to Azure.

This is one of the things I find amazing, yet frustrating at the same time. Basically everything on the Internet is based on RFC's. You have all these developers, some of which English is not their first language, from all over the world who read these documents and then write programs based on the MUST, SHOULD, and MAY's. What is amazing is that most of time all these programs actually work talking to each other. The frustrating part is you have something like JSCH which has been working with other programs for years, but doing things incorrectly. It does not come to light until you have a new program (AzureSSH) that come along and is written to the RFC.

Answer 4

The issue is with validation of the client software version string.

INFO: Local version string: SSH-2.0-JSCH-0.1.54

From SSH RFC:

When the connection has been established, both sides MUST send an
   identification string.  This identification string MUST be

      SSH-protoversion-softwareversion SP comments CR LF

   Both the 'protoversion' and 'softwareversion' strings MUST consist of
   printable US-ASCII characters, with the exception of whitespace
   characters and the minus sign (-).  The 'softwareversion' string is
   primarily used to trigger compatibility extensions and to indicate
   the capabilities of an implementation.  The 'comments' string SHOULD
   contain additional information that might be useful in solving user
   problems.  As such, an example of a valid identification string is

      SSH-2.0-billsSSH_3.6.3q3<CR><LF>

We are relaxing the validation to allow the extra "-" after the "SSH-2.0-", and the change will be available soon.

Answer 5

Any solution found for this issue ? I can see from this thread there is product fix but is that published or yet to get release.
Please let me know if there are any workaround available for this issue.