Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting Algorithm negotiation fail on version 0.1.62 #40

Closed
karand1985 opened this issue Apr 6, 2021 · 9 comments
Closed

Getting Algorithm negotiation fail on version 0.1.62 #40

karand1985 opened this issue Apr 6, 2021 · 9 comments

Comments

@karand1985
Copy link

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.

image

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
Copy link
Owner

mwiede commented Apr 6, 2021

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

Thanks a lot for your help Matthias.

Regards,
Karan

@mwiede
Copy link
Owner

mwiede commented Apr 12, 2021

Thanks to Jeremy who answered!

Closing this issue as it is located at server.

@mwiede mwiede closed this as completed Apr 12, 2021
@karand1985
Copy link
Author

karand1985 commented Apr 12, 2021

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
Copy link
Owner

mwiede commented Apr 12, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants