selecting ssh public keys for a session is broken
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)
- 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
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.
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?
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.
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?
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:
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.
Last edited by cboyack; 05-05-2020 at 03:11 PM.
|Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)|