mwiede
Providing backward compatibility with JSCH jar upgrade to latest (eg: 0.2.4)
Hello Team,
Recently we have upgraded to the latest available JSCH jar that is 0.2.4. Eventhough it works fine with few SFTP servers its creating problem with some other SFTP servers . We were getting issues like below
- Algorithm negotiation fail
- Auth fail for methods 'publickey'
Both issues we were able to fix with the hints your github link . That is by using Jsch.setConfig methods or by setting system properties in our application side. For example by setting JSch.setConfig("kex", "...") , JSch.setConfig("server_host_key", "...") and -Djsch.client_pubkey property etc .
Also we read that your suggestion is to set 20 such properties .
So for this we either need changes in our application code or on system properties based on how customer gets error. This is bit inconvenient for our customers and for us also as we need to either change code or ask customer to set the property .
So my questions are like below
- Is it possible that the jar itself provides some backward compatibility option in different way ? For example one boolean flag that if we set from our client application code provides backward compatibility and no need to set 20 different properties ?
- Also by setting 20 properties are we sure we will not get further issues based on the SFTP servers used on customer side ?
Thanks in advance Harsha.
Also we read that your suggestion is to set 20 such properties .
Where are these suggestions documented? We also started running into this issue.
What I am confused about is that isn't the security restricted by the ssh server? If the server accepts the old method, there is no reason for the client's to limit it. Are we overdoing it?
Also we read that your suggestion is to set 20 such properties .
Where are these suggestions documented? We also started running into this issue.
In the README.md https://github.com/mwiede/jsch#why-do-ssh-rsa-type-keys-not-work-with-this-jsch-fork-and-my-server
