timeout in waiting for rekeying process.

[gdevenyi]

Trying to test the new implementation from #393 (from today's dev build)

I get the following error:

SSH: ssh_eddsa_verify: ssh-ed25519 signature true
SSH: Host '10.116.134.8' is known and matches the EDDSA host key
SSH: Disconnecting from 10.116.134.8 port 22
Session Manager Error:
timeout in waiting for rekeying process.

Which leads me to this reasonably recent bug from jsch
mwiede/jsch#604

[dcommander]

Can you help me figure out how to reproduce it?

[dcommander]

Since I can't reproduce the issue, I need the following information:

• the command line you are using to generate the key (I assume you're just using ssh-keygen with a recent version of OpenSSH, but I wanted to make sure.)
• the operating system (including version) on which you generated the key
• the server operating system (including version)
• the client operating system (including version)
• the SSH configuration you are using (I presume you are using a multi-level tunnel)
• the gateway SSH server operating system (including version), if you are using an SSH gateway
• any other details (such as whether the issue occurs immediately when connecting or after a certain period of time)

[dcommander]

@gdevenyi Please answer my questions. I need to be able to reproduce the issue so I can determine whether the patch actually fixes it. Since TurboVNC 3.2 beta1 is imminent, a timely response is appreciated.

[gdevenyi]

This is due to specifics of my ssh config

I have

  ServerAliveInterval 10
  ConnectTimeout 10

To make bad connections timeout sooner and this appears to be too aggressive somewhere. But, the failure happens way earlier than 10 seconds.

Furthermore

If change to

  ServerAliveInterval 30
  ConnectTimeout 30

It still fails exactly the same way.

If I comment out these lines, the config works.

[dcommander]

I will always assume and test the default configuration unless you specify that your configuration is not the default. In the future, please include that information in the original bug report.

This appears to be a similar issue to #161, in that JSch incorrectly treats the ConnectTimeout value as milliseconds rather than seconds. I am investigating how best to fix it.

[gdevenyi]

I will always assume and test the default configuration unless you specify that your configuration is not the default. In the future, please include that information in the original bug report.

Will definitely be much more specific in the future. This is a non-OpenSSH implementation so eveything is up for grabs.

[dcommander]

Did the patch fix the issue on your end? The issue I observed was subtly different (different error message), so I'm not sure if it was the same issue.

[gdevenyi]

The timeout bug is fixed in 2025-01-22.