Opening native graphical application from remote shell

[ghost]

"OpenSSH for Windows" version
0.0.24.0

Server OperatingSystem
Windows 10 Enterprise 2016 LTSB

Client OperatingSystem
Windows 10 Enterprise

What is failing
Graphical windows are not showing in user's workspace.

Expected output
Window of graphical application should appear on user's workspace when logged in. For example if I am at the server logged in as UserA then process started in OpenSSH should open up a window on my desktop. eg. running ssh UserA@myMachine notepad.exe
I am not talking about ssh -X although it does not work either.

Actual output
Application is started but it's graphical form is somewhere in world behind a mirror.

I have also tried Windows's runas command but it did not help.
Thank you in advance.

[DarwinJS]

At a minimum, I believe that would be the "Session 0 Isolation" security feature of Windows.

You can read more about why it exists and how it works here: https://blogs.technet.microsoft.com/askperf/2007/04/27/application-compatibility-session-0-isolation/

[ghost]

Ok, so if I was to set the service to run as the exemplary UserA then it should be able to run in the Session 1. Am I comprehending it correctly?

[DarwinJS]

No all services run in session 0 by default. There is not a way to get a service to run in session 1. Additionally, any process a service simply launches runs in session 0.

There one other possible complexity in what you are expecting - even if sshd tried to launch a process as the user - it would also have to log them in and create a desktop to place the window on that you are requesting. If that is the case, this part would be a bunch of code way above and beyond simply doing "launch a process as another user". Similar to how simply launching a process as a user on linux is different than that user interactively logging on.

The options after Session 0 was worked into the OS are to run the process as a background process (instead of a service) automatically triggered when the user logs on. Or create a companion background app that is launched in the user context and the service process securely talks to it by some mechanism. Similar to above, both of these methods do not take responsibility for launching that user's logon / desktop environment - they assume it is being created by the user actually logging on.

Back when this came out I wrote VBScripts that demonstrated using the registry to talk between a service and a user process.

Also you can view what session things are running in using PowerShell's Get-Process:
Get-Process | Select Name, SessionId

[ghost]

I tried running it as a local application and not as an service but when I successfully login it always fails on fatal: ERROR. Cannot create process (1314).\n. So I am pretty lost now.
Is there some tool to run something in user's workspace as a workaround? I am ok with supplying password to the service.

[DarwinJS]

I have been explaining how session 0 isolation works in general and affects the use case you were after.

That is completely separate from whether you can successfully setup sshd.exe as a background process in your user session.

I don't think you can because sshd.exe wants to have the permissions on host key files and ssh keys locked down to the service account context it normally runs under "NT Service\sshd" (a virtual account created for any configured service).

I'm not sure if sshd.exe will run if regular users are given access to these files - but you would have to run as a regular user logon to run it as a background task.

I will let the PowerShell development team comment on whether this scenario is possible. Certainly, it does not seem like a primary use case that most people would be configuring sshd for.

[ghost]

Yes, it actually does run when I fixed the permissions but when it tries to spawn the cmd.exe it fails probably due to insufficient rights.
It is not primary use for sure, but thank you for looking into it. We use it as a workaround for executing automated tasks. We used to use FreeSSHd so we tough this would be more appropriate way but unfortunately it does not suit our needs.

[DarwinJS]

You might want to look into the windows scheduler - it is quite flexible for this:

• Works remotely
• you can trigger a task immediately
• you can trigger at task once only
• you can change user contexts (if you code their password into the job OR you schedule the job with their user id (and no password) for next logon

FYI - I love PowerShell but scheduled tasks is one area I find them unnecessarily complex, so usually end up using schtasks.exe instead.

[ghost]

Bitvise SSH Server properly manages Windows Stations, which has been a problem with OpenSSH running on Cygwin in the past. It looks like Bitvise does not, however, implement any kind of X11 forwarding-esque feature, even though it technically should be possible.

The server would have to get a handle to your user session, and launch a process in your session on one of the desktops. This is possible as far as I know, and I suspect a useful feature, but I am not sure it has been implemented in any software to date.

Many people discussing this project were interested in how it would handle Windows primitives like sessions, stations, and desktops. A comment from Microsoft on this issue would be appreciated.

[mgkuhn]

Regarding the case of sshd running as a service in session 0:

The underlying problem here is that Unix and Windows "sessions" are radically different things:

• On Unix, there was very little notion of a login session: there is just the process ancestry tree and the real/effective UID/GID under which each process runs. Access to a GUI desktop is done via the file system (Unix-domain sockets, ~/.xauth files, etc.), so if you know where to go (e.g. via the DISPLAY environment variable) and your effective UID/GID has the right file-system permissions, you can access the GUI desktop. A Unix kernel knows (nearly) nothing of GUI desktops or windows.
• On Windows there is instead an entire zoo of kernel objects called terminal sessions, login sessions, windows stations, desktops, and finally windows, some of which have their own access-control lists and associations with processes. In addition, there are security tokens.

Windows was clearly never designed to run sshd out of the box in a way that gives ssh users full access to all Windows facilities in the same way remote-desktop does. The Windows kernel architects will eventually have to provide advice (and possibly even extend the Win32 API) on how to best give ssh users full access to their very different world of sessions. See also issue #996 on how to get a Kerberos ticket (or share one with another session) from ssh for another manifestation of the same underlying architectural problem.

[ghost]

@mgkuhn: You reference the function key to implementing my suggestion in your report, namely SetTokenInformation. However, it is not possible to create sessions in this way. You can simply make a window appear on an already existing desktop within a session.

Login sessions do exist in X11 and Wayland. It is possible to keep rogue processes from accessing a user's X11 session. The main difference I am aware of is that X11 forwarding used to perform rendering client side. Anything else you see is obtuse naming.

[DarwinJS]

@mgkuhn - my understanding is that the openssh project is part of a strategy to provide winrm remoting over SSH. Windows remoting as seen in PowerShell is always text based, but does have full hooks for accomplishing remote admin.

Side point - even though winrm remoting hit the shelves with PowerShell - it is designed to meta to PowerShell and usable within other shells as shown through winrs for windows traditional shell commands.

So on the server side the idea seems to be to leave the GUI stuff in the past - very similar to the LAMP stack implementations that were common place right before containers.

If a GUI is needed the new Honolulu project enables that for the text-only Server 2016 edition (build 1709) - but it runs on a GUI enabled host and uses remoting for full management.

Here are a few links:

• https://github.com/PowerShell/PowerShell/tree/master/demos/SSHRemoting
• https://poshsecurity.com/blog/2015/6/22/why-remoting-vs-ssh-vs-rdp-shouldnt-be-a-thing
• https://docs.microsoft.com/en-us/windows-server/manage/honolulu/honolulu

Disclaimer - I don't work for Microsoft and I'm not speaking for the OpenSSH development team.

[manojampalam]

I'll get back with my findings by next milestone.

[alphaCTzo7G]

This would be super useful... as I am also trying to trigger a GUI application through ssh. I am aware of the psexec and the scheduled task, and ControlUp appoaches.

psexec is probably what I have to do.. as it seems to be most suggested approach here. However, it sends username/passwords as plaintext over to the remote computer.. which maybe a big security hole in future.

@R030t1, can bitvise ssh server overcome the session 0 isolation problem?

[ghost]

No @alphaCTzo7G, nothing can get around it. What Bitvise does is properly associate a Windows Station (something which exists within a Desktop, which exists within a Session) with programs so that they will manage to run when invoked headlessly when the server is running within an interactive session.

This issue exists because Windows treats user interaction in a way that other OSes do not. The kernel is the sole mediator of input, which makes it hard or impossible to make programs which do certain things.

[congzhangzh]

For remote ui automatic test, run sshd after login should works, two unexpected behave:

1. A unneeded teminal ui be shown!
2. Sshd exit after ssh client exit!

====

[hajya]

@maertendMSFT I would like to propose re-opening this topic given the conversations around potential broader usages in headless or remote development scenarios.

[maertendMSFT]

@hajya we will discuss
cc: @bagajjal

[mgkuhn]

An application developer can use the Win32 API functions GetProcessWindowStation and then GetUserObjectInformationA to find out the name of the window station to which the current process has access. If this is not WinSta0, then the application does not have access to the GUI desktop. This is the case for any application started from within sshd running as a service.

This is for example what the hasdesktop() function in my Julia package Desktop.jl does.