Execute command/script in Windows 10 remotely from Linux machine

autohotkeyremote controlssh

My goal is to launch a simple AutoHotKey script in Windows 10 machine from Ubuntu host within the same private network. After googling, I found winexe, which sounded like it could do what I want, but after many trials, I failed to connect it to Windows 10 ("Failed to open connection – NT_STATUS_CONNECTION_RESET", further googling didn't help). As a second solution, I've installed SSH server on Windows machine (Bitvise SSH Server). Now I can login from Ubuntu via ssh to Windows or just run commands on Windows machine:

$ ssh user@windowsmachine command

This works for regular commands like DIR, MKDIR, … but it does not work for AutoHotKey scripts. E.g., with

$ ssh user@windowsmachine 'C:\path\to\script.ahk'

nothing happens on Windows machine (launched locally, this test script just shows a greeting message box). The following attempts also do not work:

$ ssh user@windowsmachine '"C:\Program Files\AutoHotkey\AutoHotkey.exe" C:\path\to\script.ahk'
$ ssh user@windowsmachine 'cmd.exe /c C:\path\to\script.ahk'

UPDATE: The trick almost works. E.g., it does launch calc.exe:

$ ssh user@windowsmachine calc.exe

But if I launch notepad.exe or any other application, I see them in the taskmanager running as background processes, without GUI. (I don't know wjat so specual about calc. exe that it runs normally). I also managed to fix the problem with winexe, but the situation is absolutely the same as with ssh – except calc.exe, all GUI apps are launched as background processes. THis problem is discussed here. So the bottom-line is that it takes enormous effort to run GUI apps in Windows 10 from Linux host. So I just have written my own little client-server app in Qt 5, which listens to a certain port, and runs corresponding apps/scripts when a user-defined command is received from another host.

Best Answer

Windows is using sessions to display GUI applications to the users. Your ssh server is probably a windows service run by the SYSTEM user in the session 0, which is without a graphical display. Thus, you won't see the GUIs of the applications you are starting.

You can check this with the Sysinternals Process Explorer. After starting it (as admin), right click the column bar, click "select columns" and add the "Session", "UI Access", "User Name" and "Integrity Level". These information will show you for each process in which context that application is running ("Session"), whether it shows a window ("UI Access"), under which account is is executed ("User Name") and with what permissions ("Integrity Level", high means as admin).

Now, if you would like to execute an application from your ssh server in your user session, you can do so with another Sysinternals utility which is called PsExec: psexec -i <session number> -accepteula <application to execute>. If you would like the process to run with your normal user you can also use the parameter -u and you can strip permissions with -l if you so desire. Check the help running psexec -?.

To find out your sessions number, you can also run the command qwinsta. This way, you don't need the Process Explorer GUI application.

For example, to run the calculator, do the following: From an ssh session, run qwinsta, which should give you something similar to this:

C:\>qwinsta
SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
services                                    0  Disc
console           john.doe                  1  Active

So your session you would like to use is 1 in this example (it may be different for you). Then execute psexec -i 1 -accepteula calc.exe. The calculator should now show up on your desktop. (the -accepteula is absolutely needed on the first execution of the application. Without this, the application is going to show you the license agreement in a GUI window, which - of course - won't be displayed for the above mentioned reasons. On subsequent calls you can ignore the parameter, since once accepted the GUI window will not show up again)

If you prefix your autohotkey.exe command with the psexec as explained above I would expect the script to work, but I cannot test this myself since I don't know that application.

Related Question