CheckKexes introduces large latency in session connections

[Alex-Vol-Amz]

After 0.2.16 when the [email protected] was introduced I noticed an 8 second latency in new sessions created during operation in an AWS Lambda environment. I have not pinpointed what part is really causing the latency but it is the doInit() calls for the KEX checking. The latest 0.2.23 version further increased the latency to 20 seconds per new session.

Removing the newer KEX from the list in CheckKexes drops the latency back to the normal levels.

Can the CheckKexes operation be optimized so the latency is a one time only event? Perhaps caching the result for future calls in the same JVM? I would like to see a better approach to this than having a slow connection for every new session.

[norrisjeremy]

Hi @Alex-Vol-Amz,

You can adjust this to fit your own needs by changing the value of CheckKexes (via JSch.setConfig("CheckKexes", "...") or session.setConfig("CheckKexes", "...")) or by setting the system property value for jsch.check_kexes: just set it to reflect the set of algorithms you would like JSch to validate are usable.

Thanks,
Jeremy

[Alex-Vol-Amz]

Sure, I already did that and it does address the issue sufficiently. I just think it needs to be at least documented since a lot of time sensitive consumers might be surprised and confused by this hidden latency. I have not analyzed what specifically is causing such a dramatic increase in observed latency when used in AWS Lambda environment but it is surely a show stopper for some applications.

My workaround for the specific use case as you suggested was to add in my application a static block to initialize to the algorithms available with the 0.2.15 version.

static {
    JSch.setConfig("CheckKexes", "curve25519-sha256,[email protected],curve448-sha512");
}