TR Forums

Hi ,

I have installed openSSH server on a win 32 bit server machine.

I am starting a firefox process on the server machine remotely from my PC.The firefox has started.

When I login to the server machine remotely ,I see the firefox process running on the task manager.However I donot see the firefox window.

I want the firefox window started using openssh to be visible on windows.

How can I do it? Pls help

A bit of Googling indicates that you may be able to launch the remote process in the appropriate desktop session (rather than in its own, non-visible session) by the use of psexec on the remote machine:

https://www.itefix.no/i2/node/10513

The discussion is somewhat out of order, but the suggestion does look viable. I think you may have to do the remote-desktop login before launching the process, though.

This does look to be an unusually difficult thing to do; I'm not sure Windows is really designed to allow it. (It may be designed to specifically make it difficult, to avoid letting one logged-in user interfere with another.)

Remote Desktop is the better tool to use in this case.

Why do you want to access the Windows server via ssh anyway?

@The Wanderer
Windows was never designed to allow this. This works in *ix environments because X Windows was designed to be accessed over a network by a terminal. Remote access in Windows is why RDP exists.

Yup, doing what you're trying to do has been made difficult on purpose. The currently logged in session effectively "owns" the desktop; allowing background processes from other users to arbitrarily open up new windows would be a rather large security hole!

I may have totally misread that. I was thinking he was trying to run GUI processes on the remote server and have the GUI displayed on the local machine via X forwarding in OpenSSH.

There is a command built in to Windows that used to be able to launch GUI applications which would show up on the desktop of the currently logged in user in Win2000/XP days. I'm not sure if that still works for current Windows systems.

If the OP returns and posts a better explanation of the problem, I might share.

[Edited for clarity]

Yup, RDP or VNC and you can potentially throw the VNC through an SSH forwarded port to get it through firewalls and add security.

notfred wrote:

Yup, RDP or VNC and you can potentially throw the VNC through an SSH forwarded port to get it through firewalls and add security.

TBH I would not expose *either* protocol directly to the Internet, given MS's security track record and the inherently rather weak security of the base VNC protocol. I prefer to run both of them through an encrypted tunnel (typically a SSH forwarded port, as you suggest).

I put my SSH and RDP daemons on random high TCP ports instead of the default. If nothing else that will stop the bots.

Haven't tried running RDP though an SSH tunnel.

just brew it! wrote:

notfred wrote:

Yup, RDP or VNC and you can potentially throw the VNC through an SSH forwarded port to get it through firewalls and add security.

TBH I would not expose *either* protocol directly to the Internet, given MS's security track record and the inherently rather weak security of the base VNC protocol. I prefer to run both of them through an encrypted tunnel (typically a SSH forwarded port, as you suggest).

RDP is pretty decent (they started out with 40-bit encryption right off the bat and upgraded to 128-bit fairly early, around early 2000s once the export control was relaxed), except for the latest security bulletin that they patched. I also redirect the RDP port externally to a non-default one, since I do get a few port scan attempts at 3389.

bthylafh wrote:

I put my SSH and RDP daemons on random high TCP ports instead of the default. If nothing else that will stop the bots.

Haven't tried running RDP though an SSH tunnel.

I've been doing it that way for years. Just forward any local port xxxxx thru the firewall at the other end to hostname:3389, and point the RDP viewer at localhost:xxxxx.

Flying Fox wrote:

RDP is pretty decent (they started out with 40-bit encryption right off the bat and upgraded to 128-bit fairly early, around early 2000s once the export control was relaxed), except for the latest security bulletin that they patched.

That's good to know. I still feel better exposing as few services to the 'net as possible though; port 80 (HTTP), 443 (if you're running HTTPS), and 22 (SSH) should be all most servers ever need on their public-facing IP. In fact, I would argue that your SSH server should be running on a non-standard port as well (as bthylafh suggests).

just brew it! wrote:

Yup, doing what you're trying to do has been made difficult on purpose. The currently logged in session effectively "owns" the desktop; allowing background processes from other users to arbitrarily open up new windows would be a rather large security hole!

Not if it was restricted to the administrator, surely? (Assuming proper least-privilege account configuration, which would be a bad assumption on desktop Windows but hopefully not on a Windows server).

For that matter, if the process had to be launched with the credentials of the user whose session was to be used, that seems like it ought be sufficient authentication to make the whole thing reasonably safe.