1

I have machine A connecting to machine B using PuTTY. Both machines have Windows OS.

I wanted to open notepad in machine B and when I entered start notepad.exe nothing happens, but when I checked the task manager (in machine B), in the processes tab, I see that notepad is running.

Machine B has no other screens and even checking alt-tab, there is no window for notepad.

I've turned off firewall and UAC settings in case this was the cause of the problem. There also no anti-virus installed in Machine B.

Any help is appreciated!

Martin Prikryl
  • 24,007
Corl
  • 13
  • 1
  • 3

3 Answers3

1

Normally the (SSH) servers run as a Windows service.

Window services run in a separate Windows session (google for "Session 0 isolation"). They cannot access interactive (user) Windows sessions.

Also note that there can be multiple user sessions (multiple logged in users) in Windows. How would the SSH server know, what user session to display the GUI on (even if it could)?

You can run the SSH server in an interactive Windows session, instead as a service. It has its limitations though.

In general, all this (running GUI application on Windows remotely through SSH) does not look like a good idea to me.

Also this question is more about a specific SSH server, rather that about an SSH client you are using. So you you include details about your SSH server, you can get better answers.

Martin Prikryl
  • 24,007
1

SSH is not a native windows management tool (even if Windows 10 has a feature for it.) Instead, I would use psexec which allows you to run any application remotely in an “interactive” window while specifying a specific username and password to run as, as well as a specific session ID, if necessary.

https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

https://serverfault.com/questions/453704/interactive-mode-of-psexec-not-working-for-console-application

https://forum.sysinternals.com/psexec-i-does-not-interact-with-remote-desktop_topic14473.html

Appleoddity
  • 11,970
1

For a Windows Win32 process to have access to the desktop GUI, it needs to run inside window station "WinSta0". A Win32 process can query which window station it runs in via GetProcessWindowStation.

The sshd from “OpenSSH for Windows” normally is not started inside any window station, and therefore any processes that it starts will not have access to any desktop GUI. It's a command-line-only environment.

This is one of the many things where Windows is very different from Unix-like operating systems, which have nothing equivalent to a window station.

You can of course manually start sshd inside your GUI session, and then the commands it executes will run in the same window station and thereby have access to the same GUI desktop. But then sshd doesn't run all the time as a service.

To run sshd inside your GUI session, you first need to stop it running as SYSTEM (either using Stop-Service sshd in an admin powershell, or using the services.msc GUI). Then you can simply start sshd.exe from the command line in a cmd.exe or PowerShell terminal window that you have opened in your GUI session, and then ssh connections into that sshd process will have access to your GUI environment. But you now can only login via ssh into the one user account under which sshd runs, because sshd has lost the ability to change user.

See also https://github.com/PowerShell/Win32-OpenSSH/wiki/sshd or https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Markus Kuhn
  • 201
  • 1
  • 7