-
-
Notifications
You must be signed in to change notification settings - Fork 139
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
Consider switching to the JSch fork at mwiede/jsch #323
Comments
Yes, I noticed that. I will consider switching in the next major release. |
I will also look into merging some of the less disruptive fixes into TurboVNC 3.0.x. For instance, it would be nice to have support for the OpenSSH private key format. Otherwise, generating a new SSH private key and then attempting to use it directly with the TurboVNC Viewer (with the |
The patch that allows JSch to support OpenSSH v1 private keys has been merged into the main branch (which will eventually become TurboVNC 3.0.1.) |
Support for |
It seems like perhaps you used a different version of JSch in the v3.0 release? I recently updated to 3.0.2 and was surprised when my ed25519 key no longer worked:
I see you said in #331 that "TurboVNC Viewer doesn’t support ED25519 keys" so I was surprised when I retested 3.0 and it worked 😄 (I reinstalled v3.0 to verify that it does indeed work, v3.0.1 and v3.0.2 and the latest prerelease show that error, given the Thanks for your work on the SSH support, it's been very nice to use (the authentication and the session manager)! |
I am in the process of implementing a number of fixes to our SSH client based on an extensive regression test that I developed for it. In the context of fixing those issues, I have had an opportunity to examine the JSch fork closely, and my impression at the moment is that it still has a lot of quirks-- differences in behavior relative to OpenSSH that I have had to address, with some difficulty, in our own implementation. The JSch fork also relies on JNA for its SSH agent connectors, which is a non-starter for TurboVNC. Of the two features that I have ported from the JSch fork so far (OpenSSH v1 private key support and rsa-sha2-256/rsa-sha2-512 signature support), the latter of those features caused TurboVNC to regress. (See #361.) In order to adopt their code base, I would have to spend a great deal of time submitting upstream pull requests that fix and test the various quirks, as well as figuring out how to integrate as much of their code as possible without integrating the parts of it that would break TurboVNC. Honestly, it would be easier to just port specific features from their code base into ours based on user demand. That would also give me an opportunity to closely examine and regression test each new feature that I adopt. Thus, please list the features that you would most like to see TurboVNC adopt from the JSch fork. |
3d28dd1 adds explicit support for Ed25519 keys. The 3.2 Evolving builds (https://turbovnc.org/DeveloperInfo/PreReleases) now include that feature. |
JSch hasn't had a release since 2018, and it's missing many features (such as ed25519 keys).
There's a fork at https://github.com/mwiede/jsch and the changelog is quite impressive. Have the TurboVNC project considered it?
The text was updated successfully, but these errors were encountered: