Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

load savedsession file via command line? #33

Closed
Vangelis66 opened this Issue Apr 13, 2018 · 12 comments

Comments

Projects
None yet
2 participants
@Vangelis66
Copy link
Contributor

commented Apr 13, 2018

Hello 馃槂

Many thanks for the English GUI of this fine PuTTY fork 馃憤

With stock PuTTY, as you know, sessions are stored in the windows registry;
my savedsession data includes an Auto-login username;
the connection to a third party SSH server (that I have no shell access to, the SSH tunnel is used just for dynamic port-forwarding, i.e. I simply proxy other applications via the generated SOCKS5 proxy)
requires I manually type a password string in the PuTTY terminal every time I want to establish a tunnel...

On Windows, one can create a shortcut with the following content inside the target field:

"Path\to\putty.exe" -load "savedsessionname" -pw "passwordstring"

and because my login username is already included in the session data, simply double-clicking the shortcut is enough to authenticate and establish the SSH tunnel 馃憤

One of the most attractive features of your fork (iPutty) is the ability to do away with registry session storage, as in: export (load and save) the registry saved sessions (if present there) to local files, then use those files to load a session from (via the iPuTTY GUI); one can then remove all PuTTY registry keys, iPuTTY will be fine restoring saved sessions from files only...

However, the Windows shortcut template I posted above doesn't seem to work as expected; the -load switch is apparently limited only to registry saved sessions, can't load files saved locally 馃槩
Even when I explicitly point it to a saved session file (relative or absolute path):

-load "sessions/savedsessionname",

d-c the shortcut results in the iPuTTY GUI opening up, where I have to manually select+load the session from file and then hit Open; incidentally, the -pw switch still works as expected, so after clicking Open I am auto-logged in...

What I would've hoped is the ability to auto-log in in one step, by simply d-c the shortcut, without the GUI poping up; in other words, how to specify in the command line a locally saved (session) file to be loaded by iPuTTY? Can you patch your code to that effect?
Maybe introduce a -loadf ("load from file") switch that, by default, looks for files inside the sessions dir or modify current -load switch to look there, too (especially when the registry is empty) ...

Thanks in advance for your consideration, apologies if what I request is already doable in a way I have simply overlooked/ am not aware of 馃槃 ...

Regards.

@Vangelis66

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2018

... It would seem at least two (2) other PuTTY forks are already capable of the feature I'm requesting:

  1. PortablePuTTY; this is based on latest PuTTY 0.70.0 code, but, sadly, lacks the "Tray" features...
  2. PuTTYTray; this is a fork which has significantly diverged from the original code tree; latest released binary (p0.67-t029) is somewhat older (2016-06-26), built on PuTTY 0.67.0 code, and development has stalled currently, due to various issues...

Perhaps the relevant code from these two could be implemented here; that way, I could permanently switch to iPuTTY, which is current (0.70.0) and has both "portable" and "Tray" capabilities 馃憤
Thanks in anticipation!

@Joungkyun Joungkyun self-assigned this Apr 14, 2018

@Joungkyun Joungkyun added this to the 0.71 milestone Apr 14, 2018

@Joungkyun

This comment has been minimized.

Copy link
Member

commented Apr 14, 2018

PuTTYTray is always created to open the session file when using the -load option in config.c

    c = ctrl_radiobuttons(s, NULL, 'f', 2,
                        HELPCTX(no_help),
                        storagetype_handler,
                        P(ssd),
                        "Sessions from registry", I(STORAGE_REG),
                        "Sessions from file", I(STORAGE_FILE),
                        NULL);

Therefore, PuTTYTray does not work well.

Let's take a look at some more code to see if we can fix the problem.

@Joungkyun

This comment has been minimized.

Copy link
Member

commented Apr 14, 2018

And, instead of the "-pw" option, you can use the "Auto-login password"(#19) function in the template.

autopass

@Joungkyun

This comment has been minimized.

Copy link
Member

commented Apr 14, 2018

All right, I modified it to use as follows.

putty.exe -load file:session_name
putty.exe -file session_name
putty.exe -loadfile session_name
putty.exe -fileload session_name

You can choose one of the above methods.
Attach the build file, test it and let it know if it works, then commit and close the ticket.

putty-9c935c4.zip

@Vangelis66

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2018

@Joungkyun wrote:

instead of the "-pw" option, you can use the "Auto-login password"(#19) function in the template.

Thanks for your immediate response! 馃憤
As said, I am quite new to iPuTTY, coming from default PuTTY, so wasn't aware of this feature, one I know can be found in KiTTY but not in PuTTY forks; the fact most parts of the issue tracker and wiki are (of course) in Korean wasn't very helpful to me, either, in discovering this feature...

What I did was just export (with iPuTTY) to a file my session saved (in the registry) with normal PuTTY, as you can imagine, that file contained no password info and I then, again, used the -pw switch I knew works in PuTTY...

I tried to do things as you suggested, but I'm afraid I hit another bug:

  1. I loaded my saved session from file, the first time I did that in latest iPuTTY 0.70 (x86) it did not contain a saved password (the "Connection -> Data -> Auto-login password" input field was empty).
  2. My password is a 9 character alphanumeric string, all latin letters (not safe, I know, but these are expendable short-lived SSH accounts...). Either I type via keyboard or paste from clipboard, I do see nine (9) dots created in that input field; I then switch to "Sessions" tab and click Save, to save my session (including password, this time) to file; without exiting iPuTTY, if I switch back to the Data tab, I still see 9 dots in the password field; if I click Open, then the terminal opens and I successfully auto-login to the SSH server; exit the terminal window, session is ended, iPuTTY shuts down (all OK so far...)
  3. When I launch iPuTTY anew and then select+load my previously (saved and) used session, clicking Open button results in the terminal window to launch, but auto-login fails 馃槩
username@hostname's passwrod: auto-login
Access denied
username@hostname's password:

My username gets accepted, but not my password (log excerpt):

2018-04-15 05:46:37	Appending session log (raw mode) to file: iPuTTY.log
2018-04-15 05:46:37	Sent password
2018-04-15 05:46:39	Password authentication failed
2018-04-15 05:48:36	Server unexpectedly closed network connection

If I type-in my password in the terminal, then the tunnel is established!

Debugging this, I found that if I launch iPuTTY, load my saved session and then switch to the Connection -> Data tab, I am now seeing eleven (11) dots in the auto-login password input field (not the original 9), so it is my belief that when iPuTTY exits, the correct password gets mangled inside the local session file, hence a new auto-login will fail (i.e. the string sent to the server is not correct!).
So am afraid I'm going to still be using the -pw switch which, unlike the GUI password input feature, appears to function OK...

Attach the build file, test it and let it know if it works, then commit and close the ticket.
putty-9c935c4.zip

... Most unfortunately, my OS is 32-bit, while the attached compile is 64-bit; kindly provide a x86 binary for me to test...

9c935c4

I fail to locate that commit hash in either the master/localization branch... how so?

Best wishes

@Joungkyun

This comment has been minimized.

Copy link
Member

commented Apr 15, 2018

Right. Attached binary is compiled by 64bit, and re-attache 32bit files.

putty-06275376-x86.zip

And I checked the auto-login password functional test again, but it seems that I have no problem with the test results. It does not reproduce.

  1. Make new file session WORK with empty auto-login password.
  2. load WORK session, and then fill 9 chracters password in Connection> Data> auto-login password
  3. Move Session tab and Save Work session with Sessions from file.
  4. close putty and re-execute putty
  5. connect with WORK session
  6. connect success

I fail to locate that commit hash in either the master/localization branch... how so?

If push commit, the issue ends automatically. So I'm still committed to the local repository.

the fact most parts of the issue tracker and wiki are (of course) in Korean wasn't very helpful to me, either, in discovering this feature...

iPuTTY is a Korean localization version of PuTTY. So the issue or document is in Korean.

@Vangelis66

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2018

Greetings 馃槃

iPuTTY is a Korean localization version of PuTTY. So the issue or document is in Korean.

I do realise that (the ... "of course" part of my post) and I don't blame you in any way, I just stated, for emphasis, the obvious thing: Not being able to read Korean, it was hard for me to discover documented features (unless I "Google Translate" whole pages...).

and re-attach 32bit files.

Many thanks for this 馃憤 ; so now am testing iPuTTY-0.70.1-git-0627537-win32; OS is Win7 SP1 32-bit.

I decided to start from scratch; I loaded default settings, then modified that to my needs/liking and saved to file an SSH session named SSH_STUNNEL_UK_1 (physically stored in "./sessions/SSH_STUNNEL_UK_1"); as you suggested in your step 1, I initially left the auto-login password field empty.

Some modifications from the defaults in that savedsession file are:

Log file name: iPuTTY.log / Always append to the end of it
Window: 
Columns 70
Appearance: Cursor blinks / Font: Lucida Console 10-point
Behaviour: Show tray icon: normal / Accept single click to restore from tray
Selection: Windows

Connection: 
Data: Auto-login username : my username filled in (21 char) / Auto-login password: empty
SSH: ticked "Don't start a shell or command at all" / "Enable compression" (both are required by SSH provider)
Tunnels: Forwarded ports: D1080

If I create a Windows shortcut with target:
"path\to\putty.exe" -loadfile SSH_STUNNEL_UK_1
and d-c it, then the iPutty terminal launches with the SSH_STUNNEL_UK_1 session successfully loaded from file, the terminal cursor blinks and waits for password input; if that is provided, tunnel is created OK; so I guess, in the git-0627537 code you have addressed successfully my feature request in the first post of this thread 馃憤 Furthermore, if I include password string in the shortcut:
"path\to\putty.exe" -loadfile SSH_STUNNEL_UK_1 -pw passwordstring
I am able to auto-login with just d-c the shortcut, which is what I requested originally 馃憤 馃憤
However, iPuTTY-0.70.1-git-0627537 fails to be completely portable: it may be now able to load a savedsession from local file, but still offers to (and does, if you accept) save sshhostkeys in the registry 馃憥 This breaks portability and defies the logic of loading a local session file...

Let me revisit the other issue I reported (already present in stable iPuTTY 0.70.0):

  1. I start iPuTTY-0.70.1-git-0627537, select and load (from file) session SSH_STUNNEL_UK_1;
  2. Navigate to "Connection -> Data", "Auto-login password" field is (of course) empty
  3. Manually type-in (or paste from clipboard) my 9-digit pw, I see 9 black dots.
  4. Navigate to "Sessions", saved sessions field has SSH_STUNNEL_UK_1 inside it, I click "Save" to store the newly input pw info inside the session local file.
  5. Back to "Connection -> Data", "Auto-login password", still 9 black dots are displayed.
  6. Click the Cancel button, iPuTTY 0.70.1 exits.
  7. Start anew iPuTTY 0.70.1 GUI => Sessions => Sessions from file => select SSH_STUNNEL_UK_1 => Load => is displayed in the Saved Sessions field
  8. Navigate to "Connection -> Data", "Auto-login password", now there's 11 blackdots there!
  9. If I click Open button, the session is opened, but, still, auto-login fails due to wrong sent pw:
Using username "<myusername>".
FREE SSL SSH Server
-----------------------------------------------------------
This  Server provided by fastssh.com

Terms of Service :
- No DDOS
- No Hacking and Carding
- No Torrent
- No Spam.

Visit our web site :
Create SSH and SoftEther Account: https://FastSSH.com
Any feedback/queries  : fb.com/thehoster.net

Don't forget support us !

<myusername>@ssl-uk-1.serverip.co's passwrod: auto-login
Access denied
<myusername>@ssl-uk-1.serverip.co's password:

But what really defies logic is the following observation:
If I create a windows shortcut now with just
path\to\putty.exe -loadfile "SSH_STUNNEL_UK_1"
inside it and d-c, I am successfully logged-in;
so the pw is sent correctly via a cmdline invocation of iputty (local session file has pw info),
but when the stored session file is loaded from within the GUI, the pw is read/sent incorrectly (???)

I can't code myself, but I do like testing/debugging issues; this is my small contribution towards making open source-ware better! However, in this case I've spent a bit more time than planned initially, still presented with riddles that seem difficult to solve, plus causing you all that extra work!

For the time being, I think I might stay with the somewhat older PuTTYtray (by FauxFaux) and/or kitty_portable; both of them don't present any of the issues discussed in this thread (and store sshkeys locally...).
Thanks for your hard work all-the-same, maybe I'll revisit iPutty when those issues are ironed-out...
Best regards, apologies for the lengthy posts!

@Joungkyun

This comment has been minimized.

Copy link
Member

commented Apr 15, 2018

One issue has been complicated by various problems. 馃槱 (funny that use imoji)

I think there are three issues in the current ticket.

Can not load a file session from the command line. (Original issue)

In my opinion, the first issue seems to work well in the newly built version.

auto-login password does not work properly.

For this issue, it seems that the password in memory is correct, but the password retrieved from the session is incorrect.

The password stored in the session is encrypted when it is saved, and decrypted when it is loaded.

Perhaps I think, there is a problem due to differences in architecture or OS version.
The encryption and decryption process uses putty's base64 api. I guess there is a problem here. There is no problem with Windwos 10 64bit.

I think this issue should be handled as a separate issue.
It is recommended that you use the -pw option.

The host key is not saved as a file.

On this problems, I have no problem too. Perhaps the difference in circumstances seems to be causing problems.

However, there are other workarounds to this problem. iPuTTY has the ability to ignore hostkey check. See also #10

Connection > SSH > Host keys

  • Whether checking stric hostkey during login

Finally, I am very grateful for your hard work on iPuTTY. 馃憦

@Joungkyun Joungkyun closed this in 9c935c4 Apr 15, 2018

@Joungkyun

This comment has been minimized.

Copy link
Member

commented Apr 15, 2018

The issue was automatically closed due to commit push.
Open again.

@Joungkyun Joungkyun reopened this Apr 15, 2018

@Vangelis66

This comment has been minimized.

Copy link
Contributor Author

commented Apr 16, 2018

Hello again from cloudy/rainy Northern Greece (just this day) !

One issue has been complicated by various problems.

Are you aware of the English expression: Opening a can of worms ?
From my testing experience in a variety of software cases, this is not uncommon, that is, unearthing a bug will also make other dormant bugs show up... Such is (digital) life....

I think there are three issues in the current ticket.

  1. Can not load a file session from the command line. (Original issue)
    In my opinion, the first issue seems to work well in the newly built version.

Couldn't agree more 馃憤 This issue is definitely fixed!

  1. auto-login password does not work properly.
    For this issue, it seems that the password in memory is correct, but the password retrieved from the
    session is incorrect. The password stored in the session is encrypted when it is saved, and decrypted
    when it is loaded. Perhaps I think, there is a problem due to differences in architecture or OS version. The encryption and decryption process uses putty's base64 api. I guess there is a problem here. There is no problem with Windwos 10 64bit.

I think this issue should be handled as a separate issue.
It is recommended that you use the -pw option.

... And a separate issue it surely is, for which I have new test data to contribute:
I borrowed a friend's laptop with Win7 SP1 x64, so on this OS I could test both 32-bit & 64-bit binaries of iPutty. I first tested the x86 binary used previously in my tests on my own laptop, i.e.
iPuTTY-0.70.1-git-0627537-win32 (attached in this thread); I performed the same test as described previously:

  1. I start iPuTTY-0.70.1-git-0627537, select and load (from file) session SSH_STUNNEL_UK_1;
  2. Navigate to "Connection -> Data", "Auto-login password" field is (of course) empty
  3. Manually type-in (or paste from clipboard) my 9-digit pw, I see 9 black dots.
  4. Navigate to "Sessions", saved sessions field has SSH_STUNNEL_UK_1 inside it,
    I click "Save" to store the newly input pw info inside the session local file.
  5. Back to "Connection -> Data", "Auto-login password", still 9 black dots are displayed.
  6. Click the Cancel button, iPuTTY 0.70.1 exits.
  7. Start anew iPuTTY 0.70.1 GUI => Sessions => Sessions from file => select SSH_STUNNEL_UK_1 => Load => is displayed in the Saved Sessions field

But, again

  1. Navigate to "Connection -> Data", "Auto-login password", now there's 11 blackdots there!
  2. If I click Open button, the session is opened, but, still, auto-login fails due to wrong sent pw:

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 then moved on to testing iPuTTY-0.70.1-git-9c935c4-win64 (first test binary attached in this thread, the one I couldn't run on my x86 OS);
when conducting the same test quoted above, I - to my surprise - found that
when I launch the iPuTTY-x64 GUI and load from file my saved session, then switch to the Data tab, I can see the "Auto-login password" entry field populated with 9 blackdots (the correct number),
when I click Open button, the pw sent to server is being authenticated and SSH session starts!
It looks as though in the x64 binary of iPuTTY, when the saved session is loaded from file, the encrypted pw string is being correctly decrypted (9 dots), whereas in the case of the x86 binary, decryption produces an incorrect 11-dot result (which fails with the server)...
I kindly invite you to test the x86 binary of iPuTTY (putty-06275376-x86.zip) in your Win10 x64 OS, in the hope you can reproduce...

It is recommended that you use the -pw option.

Will have to, being able to only run the x86 binary on my OS; or load from file the session (which includes pw) via the cmdline/win shortcut (which, for some inexplicable reason, works; i.e. pw decrypted correctly from the cmdline, incorrectly when loaded via the GUI).

I don't think other PuTTY forks exist with the feature to store the pw inside a session file, but perhaps you could investigate the code in latest KiTTY_portable 0.70.0.3 x86, which does have that thing and works without issues in my 32-bit OS...

  1. The host key is not saved as a file
    On this problems, I have no problem too. Perhaps the difference in circumstances
    seems to be causing problems.

Even when testing iPuTTY-0.70.1-git-9c935c4-win64 on friend's Win7 SP1 x64 OS, upon first connection with the server, when I click Yes in the popup, sshhostkey was saved in the registry by default, despite the fact the session was loaded from file (not the registry, because it wasn't there to begin with...)

However, there are other workarounds to this problem. iPuTTY has the ability to ignore hostkey check

Many thanks for that; while it sort of lessens security, it retains portability in that it doesn't write to the host OS registry 馃憤

Some general remarks:
There are mainly two "schools" of PuTTY forks: The ones that stick to the original convention and write/read everything from the registry, and the ones that implement portability, writing/reading configurations (and/or sessions) from the filesystem. It is when you start mixing these two approaches that problems may arise... Often times, to minimise issues, you have to make compromises; e.g. portable putty by Jakub Kotrla can read from both the registry/filesystem, but only writes to the filesystem...

It is you as the maintainer to decide which direction to move iPuTTY to, perhaps my issue reports/requests involved a more portable-friendly iteration of the app...

FTR. while I noted min OS requirement is Win7, I was successful in running iPuTTY-x86 in my older Windows Vista SP2 32-bit laptop, where everything works as intended (minus the issues reported here), except for Terminal Window Opacity (or transparency), which is of course a minor "cosmetic" feature, not diminishing functionality 馃憤

Finally, I am very grateful for your hard work on iPuTTY. 馃憦

No, it is you doing all the hard work with coding and then making it available to users 馃
I am but a mere tester, doing my small bit (thank you, though, for acknowledging testers' contribution to open-source projects, many authors only care for PRs!).

My best wishes+regards 馃槂

@Joungkyun

This comment has been minimized.

Copy link
Member

commented Apr 17, 2018

Thanks.

The original issue is clearly resolved, so I close this ticket. And, additional issues will be tracked with other tickets.

And, from your advice:

I don't think other PuTTY forks exist with the feature to store the pw inside a session file, but perhaps you could investigate the code in latest KiTTY_portable 0.70.0.3 x86, which does have that thing and works without issues in my 32-bit OS...

KiTTY saves the password as plain/text. Therefore, there is no decryting problem.

馃憤

@Vangelis66

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2018

@Joungkyun wrote:

KiTTY saves the password as plain/text. Therefore, there is no decry(p)ting problem.

Hi; if you're indeed saying that KiTTY stores the Auto-login password string inside the locally saved session file without encrypting it, I found no evidence that supports this claim.
I had already performed an extended set of tests (just like with iPuTTY x86) on current (latest) kitty_portable.exe 0.70.0.3 x86 (on both my 32-bit OSes, VistaSP2/Win7SP1), when I input into the KiTTY GUI my 9-character password (9 letters of the English alphabet) and then Save the loaded (from file) session SSH_STUNNEL_UK_1, once I exit kitty_portable and open the local session file with a Text edtor, nowhere inside that file can I spot my unencrypted password; in fact, the relevant line reads:
Password\bn1xpiqiPiui3i7iwidiNi7\
And when I relaunch kitty_portable.exe, select (from file) and load session SSH_STUNNEL_UK_1, the Data tab correctly displays a 9-blackdot password entry:

kitty-win32

Clicking the Open button (left-down) will establish a successfully authenticated SSH session:

kitty-ssh

If by your quoted statement you meant something else, then apologies for misunderstanding you...
As to what concerns iPuTTY-x86, I'll continue the discussion in the newly opened #39 馃憤

EDIT:

Password\bn1xpiqiPiui3i7iwidiNi7\

I just noticed that this saved string changes each time KiTTY is launched and then exited; now the same line reads: Password\1461b0i0%2F0z0g0A0P0v0y0A\ without me changing the actual 9-char password (?????)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.