selecting ssh public keys for a session is broken

[Jackson1]

there is a bunch of bugs within the context of selecting ssh public keys for a session

i'm describing one specific thing, that i can easily reproduce on my computer, but there is more bugs. (Windows 10, SecureCRT 8.7.1)

1)
- select a session
- open session options
- SSH2 -> Authentication -> Publickey -> Properties
- Assuming you had "Use session public key settings" chosen before
- and previously you had: "Use identity or cert. file" => C:\ssh\key1.pub
- now you want to change key1.pub to a new key
- you do:"Use identity or cert. file" => C:\ssh\key2_new.pub
- click OK
- click OK
- connect to your session
- now it will still use the old key1.pub
- you can verify this by removing key1 from your serverin (authorized_keys)
- you will have to restart SecureCRT to force it to use the new key2_new.pub
- once restarted, it will successfully use key2_new.pub to connect to your session

there is also some bugs when switching between global and session public key settings. or when you are connected to your session multiple times, and you change the session settings on one of them, they are not properly saved, because you have multiple connections of the same session opened, and only once you close the last one, it will overwrite the new settings with the old settings. or something like that.


other than this bugs, and especially the one i described, there is a few other improvements that should be done:

2) display the username that was used to connect to a session, i.e. the tooltip of the connected session tab. right now it only shows just the session name (again). the tooltip could show more info: username, port?, used auth. method and used public key

3) make the UI faster. opening the session options takes about 1sec on my brand new ThinkPad X1 Carbon, Intel Core i7 8th Gen. Did you guys switch to Electron? ;-)

4) saving session options of a connected session will blink the Session Manager UI like 5 times, probably some UI refresh bugs.

5) renaming a session takes 1-2sec (now there is even a dialog telling you it's slow!)

6) searching in the session manager (Find) takes 2-3 sec (I have just approx. 600 sessions saved, not 600M)

7) sometimes, the disconnect button has to be hit TWICE in order for it to disconnect a session. this behavour is a bit random and has been around for a decade or two

happy to add a few more things once we are making some progress with these!

many thanks and best wishes
- SecureCRT user since 1999

[cboyack]

Originally Posted by Jackson1

there is a bunch of bugs within the context of selecting ssh public keys for a session

i'm describing one specific thing, that i can easily reproduce on my computer, but there is more bugs. (Windows 10, SecureCRT 8.7.1)

1)
- select a session
- open session options
- SSH2 -> Authentication -> Publickey -> Properties
- Assuming you had "Use session public key settings" chosen before
- and previously you had: "Use identity or cert. file" => C:\ssh\key1.pub
- now you want to change key1.pub to a new key
- you do:"Use identity or cert. file" => C:\ssh\key2_new.pub
- click OK
- click OK
- connect to your session
- now it will still use the old key1.pub
- you can verify this by removing key1 from your serverin (authorized_keys)
- you will have to restart SecureCRT to force it to use the new key2_new.pub
- once restarted, it will successfully use key2_new.pub to connect to your session

First off, thank you for the time you spent putting this information together for us. We at VanDyke strive to make our products the best they can be, and information you provide is what helps us continue to do so.

Unfortunately, I was unable to replicate the issue described above using my own system. I tried multiple ways to "break" the publickey configuration as you described but was unable to do so. Every attempt on my end to change the settings and reconnecting to the session resulted in the newly specified key being utilized for that connection.

• Would you please help me better understand what is occurring on your system by sending more detailed instructions along with a trace options log to support@vandyke.com? Please ensure that your email subject references "Forum Thread #14167".

Trace options logs contain user data that would be too sensitive to post on public forums, thus the email request.

Originally Posted by Jackson1

there is also some bugs when switching between global and session public key settings. or when you are connected to your session multiple times, and you change the session settings on one of them, they are not properly saved, because you have multiple connections of the same session opened, and only once you close the last one, it will overwrite the new settings with the old settings. or something like that.

This sounds like 2 different problems.

For the 'bugs' that occur with switching between global and session pk settings, can you please send me some more detail so we can start looking into a fix?

The second behavior you described is not a bug, but rather a long-standing behavior in which the last copy of a session to close is always the one with its config written to the .ini file. It sounds like you'd prefer to have the option to broadcast all Session Configuration changes to all other instances of SecureCRT so that any in-memory copies of a modified session will be updated.

Assuming my understanding is correct, I've added a feature request on your behalf so that the product director may be able to evaluate it for potential inclusion in some future release. I don't yet have any ETA for when or even if this might ever become available, but if it does we can let you know.

If I've somehow misunderstood what you're asking, would you be so kind as to clarify?

Originally Posted by Jackson1

2) display the username that was used to connect to a session, i.e. the tooltip of the connected session tab. right now it only shows just the session name (again). the tooltip could show more info: username, port?, used auth. method and used public key

For this item, I have also added a feature request, as above.

Originally Posted by Jackson1

3) make the UI faster. opening the session options takes about 1sec on my brand new ThinkPad X1 Carbon, Intel Core i7 8th Gen. Did you guys switch to Electron? ;-)

I've asked our DEV/QA team to look into this issue further.
I don't yet have any ETA as to when/if the problem might be resolved, but as soon as a potential resolution becomes available we'll post to this forum.

• In your case, is your Config on your local system or on a network share?
• Does the delay occur for every session?
• What exact method are you using to open Session Options?

Originally Posted by Jackson1

4) saving session options of a connected session will blink the Session Manager UI like 5 times, probably some UI refresh bugs.

Can you provide steps to replicate this issue (with step 1 being launching SecureCRT and the last step being noticing the blinking) so I can know exactly what you're doing to trigger this blinking refresh?

Originally Posted by Jackson1

5) renaming a session takes 1-2sec (now there is even a dialog telling you it's slow!)

I've asked our DEV/QA team to look into this issue further.

Originally Posted by Jackson1

6) searching in the session manager (Find) takes 2-3 sec (I have just approx. 600 sessions saved, not 600M)

I've asked our DEV/QA team to look into this issue further.

We have noted in our tests that if a string we're searching for occurs in a session deep in the session tree, there is up to a 2-3 second delay. In contrast, if one of the first sessions contains the search string, the operation is instantaneous.

Does this sound like the behavior you're experiencing?

Originally Posted by Jackson1

7) sometimes, the disconnect button has to be hit TWICE in order for it to disconnect a session. this behavour is a bit random and has been around for a decade or two

When you first click the disconnect button, SecureCRT sends a close channel request and waits for server confirmation. Some SSH servers don't respond in a timely manner to this close request. If the disconnect button is clicked a second time, SecureCRT bails on the "nice" close, and forcefully disconnects from the SSH2 server.

If you don't care to wait for the server to respond to the nice close request and always want your first click of the disconnect button to destroy your SSH2 connection, you may navigate to Options > Session Options... > SSH2 > Advanced, and enable the "Force session channel to close on disconnect" option.

You can employ the power of editing the Default session to make these changes to all of your existing and future sessions. Here are some links to a tip and a video that provide more details about using the Default session to make mass changes to multiple sessions:

• https://www.vandyke.com/support/tips/defaultset.html
  
• https://www.youtube.com/watch?v=5RbuZn9L48g

Note: In order for a "change" to be applied to all other sessions, the Default session's option/field you're targeting must actually be modified/different from its current value. This means that if the targeted field you want to apply to all other sessions is already set to the value you want, you must first change it to something different (and apply that "change") and then edit the Default session again to set the option to its desired value (and apply that "change").

With regard to my requests for further information, it would be advantageous to respond with an email so as to keep continuity (and security for your information) regarding these issues.