Refuse to launch graphical applications from a remote shell.

[fpqc]

In a *nix environment, trying to launch a graphical (X11) application when in an ssh session will fail because no X11 server will be specified (and specifying a display on the server will likely fail because the X11 server running will require authentication ordinarily unavailable to the remote user. Such an application can be launched if SSH is launched with the -X flag, which enables X11 forwarding over the wire.

Since Windows does not directly use X, and most Windows applications are not X clients, launching them on a remote Win32-sshd should either fail, or if not fail, launch the application over something like remoteapp/rdp (assuming the -X flag is specified).

Example of the problem: ssh into a Windows box running Win32-openssh, and launch calc. This calc application is inaccessible to both remote and local users, but it will be visible on the SSH server in the task manager.

[SteveL-MSFT]

The -X parameter is strictly tied to X11 and Windows doesn't support X11 (although you can install 3rd party X-Servers). Automatically wrapping it in RDP/remoteapp would be interesting, but seems outside the scope of OpenSSH.

[fpqc]

@SteveL-MSFT Then maybe launching, for example, calc should fail with the error "Cannot locate display"

[SteveL-MSFT]

I can see how this can be useful if there is a configuration setting for this as this is a change in behavior on how Windows remoting has worked, but would be shell specific and probably implemented in, for example, powershell exe rather than in OpenSSH.

[csawyerYumaed]

While fancy stuff like RDP is interesting, I'd much rather that just bog standard -X worked, assuming an X11 server installed like vcxsrv or xming and the like. PuTTY manages.

[FranklinYu]

So VcXsrv is not supported by this version of Portable OpenSSH right? What a pity, it works so great with PuTTY. So it is too early to uninstall PuTTY in favor of OpenSSH?

[fpqc]

@FranklinYu Windows doesn't use X for Windows apps, which was the topic here. If you are launching remote Linux apps, I believe that win32-openssh does support forwarding X to a local x server.

[FranklinYu]

@fpqc VcXsrv is exactly the “local X server” you mentioned, and it works with PuTTY. I didn’t mean that Portable OpenSSH should come with an X server (not sure whether that is a good idea), but it should support existing local X server (Xming or VcXsrv).

[fpqc]

You aren't paying attention. I am talking about connecting from linux or windows to a windows shell (cmd or powershell) on a remote windows computer running openssh-server

[FranklinYu]

@fpqc Sorry I got confused. In your case the remote machine is Windows, but in my case the remote is a Linux, right?

[fpqc]

Yes. I think X forwarding from a Linux remote to Windows local machine running win32-openssh should work as usual, but I am not sure and haven't tried.

[FranklinYu]

Then we are talking about the exact same scenario, and I have not explained it well.

background

I know some basic concept about SSH connection, but I have no idea how X-Forwarding works.

My remote is a Linux VM, with some GUI application installed. My local machine is Windows, with Portable OpenSSH (aka Win32-OpenSSH) installed. X server is also installed in local Windows machine, that is the “VcXsrv” I mentioned.

Portable OpenSSH story

I started the local X server on Windows on localhost:0.0, then ran

DISPLAY=localhost:0.0 ssh -X franklinyu-linux

I expected this to “just work”, but in the SSH session, DISPLAY is empty. I started xclock to test; it complained that DISPLAY is not set. I manually set export DISPLAY=franklinyu-windows, then xclock said something like “X authentication failure”.¹ I suppose that authentication information should be forwarded by the SSH client (Portable OpenSSH in this case). I quit the session and started another with verbose flag; I saw something like “authentication failed” at the beginning.

_{1. I’m not with my machine now, sorry. I may find the exact message tomorrow.}

other experiments

I tried PuTTY (because there is many tutorials for PuTTY + VcXsrv). Simply replacing OpenSSH with PuTTY worked (PuTTY need to be told about $DISPLAY and X forwarding, of course), with all the other building blocks (X server, remote Linux) unchanged. This is my current solution, but I really prefer this project over PuTTY, for obvious reason.

I tried (temporarily) disabling authentication in my local X server (VcXsrv). After that I manually set $DISPLAY environment variable, then it worked: all my GUI application were able to be started from SSH session. However, in this case I suppose there is no X Forwarding, and there may be security concern.

[fpqc]

file a new issue