Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Auto-login password abnormal operation #39
Auto-login password does not work properly on Windows 7 32bit device. Also he reported that he would login successful on Windows 7 64bit machines.
So, this bug is still there in the x86 flavour of iPuTTY (load from file - in the iPuTTY GUI - a saved session containing auto-login password info), even on Win7 x64 !
I tested with the VirtaulBox Windows 7 32bit image from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/.
However, I could not find the problem. There was no problem logging in as shown in the image below.
It is not an OS or architecture problem, but an environmental problem on the PC where the problem occurred.
This ticket will remain on hold until there is a response from the reporter.
... Thanks; do realise though we're many time zones apart, plus real life issues and other work/projects on my laptop meant I could not respond that promptly to #39 (comment)
OK, I fetched what is the debug version of iPuTTY-0.70.0-x86 (win32), or at least that's what it claims to be...
OSes that was tested on (actual 2 different machines, not VMs):
TL:DR: The issue persists on all 3 OSes tested, actually the debug version is worse in that context to the non-debug binaries already provided for testing.
What I did:
Launch iPuTTY (hitherto implies the putty-debug-x86.exe binary), select from file and load the session with no password previously saved inside it, type via keyboard the password (9 letters of English alphabet), return to Sessions tab and
(If, at that point, I click the
... then switch to the
Instead of a 9-dot pw, there are now twenty (20) dots in the pw field (only 18 captured in the snapshot); with previously tested binaries, it was eleven (11) dots instead of 9...
Please note that the "decrypted" part of the pw I have enclosed inside the blue-lined rectangle actually contains the correct 9 characters of my pw, but is then appended with the red-lined rectangle gibberish, which seems to contain random parts with every other iPuTTY invocation...
As stated, the issue I face involves only the 32-bit binaries of IPuTTY, but is still reproducible (by me) when running these on a x64 OS (Win7 SP1); I don't have access to Win8.1/Win10 of either architecture to test
I am able to reproduce on two different machines, with vastly different setups:
Possible but unlikely both machines suffer from the same ailment...
It is unfortunate
Remember, you have to select
I think I am finished testing; you and I have spent considerable time on this; unless others can step up, I can perfectly live with the simple workaround, that is issue the password string (in plain/unencrypted form) in the cmdline via
Thanks for test.
I have a question.
I understood that the decrypted string consists of complete passwords and additional garbage data. Is right?
For example, if the actual password is
If what I understand is right, padding of base64 decoding seems to be a problem.
Thanks, but I am not sadly young. I'm getting closer to 50 years old.
You nailed it (exactly that)!
I did some further tests; you said previously that iPuTTY uses PuTTY's base64encode to encrypt and store the password string inside the savedsession local file; let's use for testing the fake password
Now, I open putty-debug-x86.exe GUI, load session, input
Launching iPuTTY, selecting and loading session with fake pw, then switching to
which suggests that the pw is correctly decrypted (but of course fails to authenticate, being a fake one)!
ISN'T ALL THIS JUST PURE MADNESS????
If I'm still sane, this implies the problem may lie with my actual (non-fake) password string, which creates decryption errors only on the x86 version of iPuTTY (????????)
I've taken the liberty of acquiring the e-mail address on your public GitHub profile (any affiliation with Daum PotPlayer?) and shall forward that password string for further troubleshooting on your part...
Thanks for your patience, I am certainly going mad myself...
Crossed that bridge some years ago...
e-mail sent (check spam folder in case gmail filters it!)
Unfortunately, I will be unavailble for the next 3 hours (leave home; still on the 18th here) and I fear it's already very early in the morning in Korea as it is; testing will have to wait until I get back, or until tomorrow, perhaps...
Looking at the results of your test, I think the problem seems to fit with what I think. I will look at the test results, and I will continue to look at the emails if they continue to have problems. (If there is no problem, I will delete it without seeing it.)
Don't worry. It is early morning as you think. Now I'm going to sleep. you can test it slowly or don't test.
Absolutely, thank you for your testing.
... OK, back to testing latest attached x86 binary, putty-debug-2.exe, modification timestamp 20180418192635Z:
As previously, same steps were followed:
Relaunch the iPuTTY configuration GUI, select and load from file the session named
In all honesty, I have to admit that was one of the most nasty and sneaky software bugs I have ever come across:
That behaviour made it very hard for the maintainer to reproduce, since nowadays most OSes (MacOS, Linux, Win10) are 64-bit (and users choose to install 64-bit apps), and even harder for me to convince said maintainer I was actually experiencing the bug, not making this all up in my head
Anyhow, all's well that ends well, my most sincere congratulations to the dev for squashing that bug!
I trust you totally with the content of my e-mail; you can safely view it after Apr 25th, when my account will have expired, to see the actual pw that was causing my issue (and further tailor your code, if it's needed).
Thank you for believing in me thus far, many thanks for the actual fix!
Now, with two out of three issues (reported by me) resolved, you'll have to improve iPuTTY so it's able to save sshhostkeys to the filesystem also, not only in the registry; perhaps a user selected setting could be introduced inside the GUI or something more automated
Cheers and best regards
Okay, then this ticket will close. And I plan to release it at 0.70.1 this weekend.
This problem is somewhat confusing. Is this the case other than the test I've done?
My tests and results are:
All of the tests below are for connection using file session.
Case 1. If the key is in the registry and not in the file system (sshhostkeys/):
A pop-up window appears for the next process.
Case 2. If key does not have both registry and file system (sshhostkeys/):
Case 3. If the key is not in the registry and is in the file system (sshhostkeys/):
The connection succeeds without any message.