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 we send the Client: Key Exchange Init. Establishing the same connection with filezilla we dont have this issue.
comparing the packages from jsch and filezilla i didn't see an obivious issue, 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.
Request with JSCH (not working)
Request with Filezilla (working)
Response with Filezilla (working)
See below for the 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
EDIT: following jameses suggestion i got the same result, connection closed but the client request only had the supported algos as payload. So i tried to replicate the FileZilla request by setting the jsch config regardless if jsch actually supports the algo, i just wanted to see if there is any respone.
But for some reason the connection still gets terminated
Santiago Trujillo
i wanted to post a quick update for anybody that is having the same issue, i opened a similiar question on the microsoft q&a site and looks like it's an issue on the azure side that they are working on fixing for GA Microsoft Q&A
Thanks to the latest comment (from JGiltner62-0227 on 2022-02-18) at https://docs.microsoft.com/en-us/answers/questions/713024/connection-to-azure-sftp-doesnt-work-using-jsch.html I now have a working JSCH implementation. There are two things that need to change in the source code, both in Session.java.
private byte[] V_C=Util.str2byte("SSH-2.0-JSCH-"+JSch.VERSION); // client version
needs to change to:
private byte[] V_C=Util.str2byte("SSH-2.0-JSCH_"+JSch.VERSION); // client version
(The difference is an underscore instead of a dash after 'JSCH').
byte[] foo=new byte[V_C.length+1];
System.arraycopy(V_C, 0, foo, 0, V_C.length);
foo[foo.length-1]=(byte)'\n';
needs to change to
byte[] foo=new byte[V_C.length+2];
System.arraycopy(V_C, 0, foo, 0, V_C.length);
foo[foo.length-2]=(byte)0x0D;
foo[foo.length-1]=(byte)'\n';
(the variable 'foo' needs to be V_C.length + 2 instead of +1, and then we insert 0x0D as the second to last byte.)
After making these two changes I confirmed that the library works uploading to Azure SFTP.
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>
It seems that this library (and ssh-keyscan) violate the spec due to the "-" in the softwareversion segment: JSCH-0.1.54
As Fabian points out, the "fix" will be available before SFTP GA.