Consider adding Certificate Support to Jsch. about turbovnc HOT 11 CLOSED

Yes, I am using an agent. This is the method of operation used with the OAuth based ephemeral certificates.

My request here was just based on bringing the default set in line with OpenSSH, however I didn’t realise there was a different acceptance method whether a key is through an agent or loaded directly (this might explain why another program I use which supposedly doesn’t support certificates is also working).

from turbovnc.

Will look into this for the next release.

from turbovnc.

Should be implemented now, and pre-release builds with the fix will be available shortly.

from turbovnc.

Please test and make sure I didn't screw something up.

from turbovnc.

Thanks so much, I’ll take it for a spin next week

from turbovnc.

Tested, works well. Thanks. :)

from turbovnc.

Further information:

This appears to be the same issue as #360. Specifically, JSch doesn't support SSH certificates, but they used to work in TurboVNC 3.0 as long as the certificate was provided by an SSH agent. Certificates stopped working because of d6ae34d in TurboVNC 3.0.1, which introduced the PubkeyAcceptedAlgorithms keyword and caused JSch to reject any algorithm that wasn't specified in PubkeyAcceptedAlgorithms, including for agent-provided keys. JSch can technically use any key provided by an SSH agent, regardless of whether it explicitly supports the key's algorithm, but filtering such keys based on the value of PubkeyAcceptedAlgorithms is consistent with the behavior of OpenSSH. I consider that to be a feature, because it allows users to explicitly disable the use of certain algorithms both for explicitly specified keys and agent-provided keys.

Can you confirm that you are using an SSH agent? If not, then how are you using the certificate with the TurboVNC Viewer?

from turbovnc.

Yeah, when a key is provided by an SSH agent, the agent is responsible for decrypting it, so the SSH client doesn't actually need to support the key's algorithm.

It is slightly problematic for the default value of PubkeyAcceptedAlgorithms to contain algorithms that aren't technically supported by the SSH client. However, I also understand that adding an OpenSSH config entry for every host is too much to ask. What if the TurboVNC Viewer implemented the global PubkeyAcceptedAlgorithms keyword and the +/- syntax for that keyword, so you could simply add PubkeyAcceptedAlgorithms +<whatever_certificate_type> to the top of ~/.ssh/config rather than having to specify it on a per-host basis? If that would create an undue administrative burden (such as if you would need to do that for 500 users in your organization), then I am OK with keeping things as-is. (The current solution is only "slightly" problematic, because we don't advertise any certificate algorithms other than the ones that correspond to the algorithms we already support.)

from turbovnc.

I'm happy to go with whichever form is the most technically correct, and I think you're right that the certs should be removed from the default since JSch cannot decrypt them itself.

Having the +key type would definitely be good since it would make the config files must simpler and future proof (which was part of my concern with brute forcing the accepted keys, potentially having to reconfigure to access higher strength keys later) and it would also be nice if you had a way to match the wildcard behaviour, although I accept that that might take a fair bit more work.

I also encountered a problem with the Windows installation of OpenSSH being too old to support the new PubkeyAcceptedAlgorithms keyword so I was using the IgnoreUnknown keyword to get around this problem, although I have since discovered the PubkeyAcceptedKeyTypes is the legacy option which should work in both.

I can manage the updating of ssh_config files with the installation of a new version without a problem so that wont be an issue.

from turbovnc.

OK, cool. Since there is already code in the JSch form for implementing the +/- syntax, I think that's the way to go.

from turbovnc.

fbaadc2 has been reverted, and +/^/- syntax for the PubkeyAcceptedAlgorithms/PubkeyAcceptedKeyTypes keyword has been added, so you should now be able to add

PubkeyAcceptedAlgorithms [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

to the top of ~/.ssh/config to achieve the same effect that fbaadc2 achieved (no wildcards, though.) GitHub Actions is derping for some reason, so only Windows and macOS pre-release builds are available with the changes at the moment.

from turbovnc.