Feature request: session reconnect / clone

[opbod]

Hi there, thanks for going through the rabbit hole of forking PuTTY and keeping up with releases!

I'm a KiTTY user for years, but unfortunately it's not very actively developed any longer as for each new PuTTY release, one needs to start (almost) from scratch. In your intro I read PuTTie differs from this, so there's hope :-)

One of the most used KiTTY features not available in PuTTie is session reconnect and session clone. It allows to press to reconnect using the same credentials, after e.g. returning from standby or after network disconnect.
Is this something that may be added in future releases?

Also, I wanted to point out 'CVE-2024-31497: Secret Key Recovery of NIST P-521 Private Keys Through Biased ECDSA Nonces in PuTTY Client'. Assuming PuTTie is also impacted, this is something that deserves some attention.

Thanks again!

[opbod]

Thanks @lalbornoz for the quick action on both the CVE and the feature request!

The session clone seems to work; session reconnect not quite yet: a username/password is still requested upon reconnect. Not sure whether you were intending to have this functionality in the new release.
I tested this by connecting to a server, disconnecting from WiFi, waiting for timeout (Network error: Software caused connection abort), hitting to try to reconnect -> nothing happens. When picking 'Restart Session' in the menu, I'm asked for a username/password, which isn't expected for session reconnect functionality (KiTTY).

[lalbornoz]

Oh hey, you caught me right while I was rather sick w/ COVID or some such, totally forgot about you after the CVE fix from upstream, sorry about that. I'm kinda busy w/ other stuff right now but I'll get back to this as soon as possible, this shouldn't take much to implement. Session clone was already there, though w/o caching credentials across sessions, which I'm assuming is what's sought after here.

[opbod]

Correct assumption - thanks!

[lalbornoz]

Initial implementation is in PuTTie-file-Release-4fe80e3f and PuTTie-registry-Release-4fe80e3f, can you confirm that this works as intended?

[opbod]

Thanks!
I tried with the file release (commit 4fe80e3f) and for me it doesn't seem to work.

I tested this by connecting to a server, disconnecting from WiFi, waiting for timeout (Network error: Software caused connection abort), reconnecting to the network, hitting on PuTTie to try to reconnect -> nothing happens. When picking Restart Session in the menu, I'm asked for a username/password, which isn't expected for session reconnect functionality (as seen in e.g. KiTTY).
Also, when picking Duplicate Session during an active session, I'm asked for a username/password. The expected functionality would be to use the cached data and start the session right away.

[lalbornoz]

Did you [x] Cache passwords in Frippery -> General pointless frippery beforehand? This is disabled by default.

[opbod]

Thanks for the pointer, I did not 😄

Further testing:

• When setting the option and connecting on the fly (i.e. without saving) the feature does not work.
• When setting the option, saving the session and then connecting, the feature does work: I'm able to duplicate the session without entering credentials and I'm able to reconnect. Would be great if a reconnect is attempted when pressing (just like KiTTY does) - that avoids the need to take the mouse, right click on the title bar, find the exact menu.

Keep up the good work! 🚀

[lalbornoz]

* When setting the option and connecting on the fly (i.e. without saving) the feature does not work.

I'm not sure I follow here. When I start PuTTie, [x] Cache passwords in Frippery, then connect somewhere, login w/ a password, then restart that same session or duplicate it, the password is cached as expected. Is this not the case for you?

[lalbornoz]

Sorry, messed up editing your comment instead of mine. Looking into this now.

[opbod]

No worries.
I tried with both with session duplicate and with session restart (after timeout). When an 'on the fly' session is started, neither clone nor session restart work properly, as I'm asked for a username/password again.

To be clear: with saved sessions this functionality does work. One optimization point might be the use of simply pressing to reconnect per the above comment.

[lalbornoz]

When you start an 'on the fly' session w/ [x] Cache passwords, is it just asking for the username or for both the username and the password?

[opbod]

Both username and password are asked for.

[lalbornoz]

Well, I can't reproduce this at all. I'll try later on Windows, though I doubt that this is a wine vs. Windows issue.

[opbod]

Odd. Just tried once more, doesn't work. Is there anything I can do to help debug?
Running PuTTie on Windows 10 22H2.

[lalbornoz]

I'll prepare a debug build for you today or tomorrow.

[lalbornoz]

Can you do the same thing you did before w/ this debug build: https://www.luciaillanes.de/assets/putty-debug-cachepassword.zip and provide me with the debug console log after having done so?

[opbod]

Sure! Attached the logs of both debug windows (first the one when starting PuTTie, then the one when attempting 'Duplicate Session'). I've removed some personal data from the logs (xxx/yyy) and from the screenshot (red).

puttie_debug1.txt

[lalbornoz]

Thanks! However, you've not proceeded to entering your username in the duplicated session, so the debug log didn't get to the part where the cached password would've (or not) been sent. Could you repeat the above process and also provide your username in the duplicated sesson and upload the debug log again?

[opbod]

And not sure if this intentional: in the debug build, when saving the session, Duplicate Session functionality does not work either. Duplicate Session does work (when saving) in the recent release [4fe80e3f](https://github.com/lalbornoz/PuTTie/releases/tag/PuTTie-file-Release-4fe80e3f).

[opbod]

Thanks! However, you've not proceeded to entering your username in the duplicated session, so the debug log didn't get to the part where the cached password would've (or not) been sent. Could you repeat the above process and also provide your username in the duplicated sesson and upload the debug log again?

When providing the username, I'm able to login without password. The log goes attached.
puttie_debug2.txt

[lalbornoz]

When providing the username, I'm able to login without password. The log goes attached. puttie_debug2.txt

This feature solely implements caching passwords, not usernames. You can configure a username to automatically login w/ with Connection -> Data -> Login details -> Auto-login username.

[lalbornoz]

Session reconnect on disconnect will be implemented in a separate commit/release.

[nanaya]

I'm using 7604753 and have "Automatically restart session on disconnect" checked but it doesn't seem to do anything after disconnected? The window just hangs (in the sense it does nothing).

The event log looks like this:

2024-12-03 15:10:28	Opened main channel
2024-12-03 15:10:28	Allocated pty
2024-12-03 15:10:28	Started a shell/command
2024-12-03 15:10:38	Remote side unexpectedly closed network connection

Also I can't find the "Restart session" in the menu nor an option to enable that.