Getting Algorithm negotiation fail on version 0.1.62

[karand1985]

Recently we had requirement to upgrade Jsch to support openSSH 7.8.
We upgraded the jsch to 0.1.62 from maven repo.
However when connecting the session using username, password method we are getting "Algorithm Negotiation Fail" on windows environment.

The same piece of code works fine when using Jsch version 0.1.54 jar

Our Environment
OpenJDK 1.8.0_252
Windows Server 2016
Tomcat 8.5.55
Freeftpd version 1.0.13

[mwiede]

Thanks for reporting this issue. Can you please post thé log output like it is done in https://github.com/mwiede/jsch/blob/master/examples/Logger.java
Thanks

[karand1985]

Hi Matthias,
Thanks for your prompt reply.

Attaching the log file that we generate when doing sftp connection. have printed logs in debug level

FTP-jsch-0.1.62.log

Please have a look and let know.
Code snippet as below

JSch jsch = new JSch(); Session session = jsch.getSession(<username>,<host>,<port>); session.setConfig("StrictHostKeyChecking", "no"); session.setPassword(<password>); session.connect(); // Exception occurs here...

Please guide us in case if we require any code change for connecting via username password method.

Thanks,
Karan Dave.

[norrisjeremy]

04d3ff1 changed the default crypto algorithms to more closely align with modern OpenSSH.
But your server only appears to support older KEX algorithms: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
To work with 0.1.62 and your server, you will probably need to add something like:

session.setConfig("kex", "diffie-hellman-group14-sha1," + session.getConfig("kex"));

[karand1985]

Hi Matthias,
Thanks for your prompt reply.

Your suggestion worked and we are now able to connect on windows machine. Thank you.
However I have a queries...
Mine is a developer machine and hence it might be that the server has support for only older KEX algorithms.

session.setConfig("kex", "diffie-hellman-group14-sha1," + session.getConfig("kex"));

1. So suppose with the fix given above, if I deploy it on the latest server which has support for new better algorithms, will it use the new more secure algorithms or the one I have set in the session config ?
2. Will it give an security alert in case if we are using older KEX algorithms on servers that have new versions available ?
3. When testing on the server with openSSH 7.8+ would the setting of the above config result in any error or exception ?

Once again thank you for your help.

Regards,
Karan Dave

[norrisjeremy]

Hi Karan,

Yes, if the newer server announced support for diffie-hellman-group14-sha1 in it's KEX list, then JSch would negotiate the less secure algorithm (if using the example I provided).

You probably could adjust to instead do this, so that diffie-hellman-group14-sha1 was appended to the list instead of being prepended. This would allow JSch to negotiate a stronger algorithm if it is available and only fall back to the less secure diffie-hellman-group14-sha1 if no other KEX algorithm was announced by the server:

session.setConfig("kex", session.getConfig("kex") + ",diffie-hellman-group14-sha1");

I believe OpenSSH 7.8+ should work, regardless of whether you append or prepend the diffie-hellman-group14-sha1 KEX, as JSch would just negotiate one of the more modern (stronger) algorithms.

[karand1985]

Thanks a lot for your help Matthias.

Regards,
Karan

[mwiede]

Thanks to Jeremy who answered!

Closing this issue as it is located at server.

[karand1985]

Thank you all for your help in helping to resolve this issue.
The change suggested worked fine on windows and linux machines both.

Just few question:

1. Is it safe to use this jar in the production environment ?
2. Does it have any known vulnerability that can come up in any 3rd party scans ?
3. Any other thing that i need to know before using this jar and fix on the production environment ?

Regards,
Karan Dave

[mwiede]

to answer your questions:

1. the original jsch has been used many years by many people also in production environments.
2. not i am aware of
3. this is open source software. Check the text of the license https://github.com/mwiede/jsch/blob/master/LICENSE.txt

Kind regards
Matthias