Thanks for the link. I am slowly trying to catch up on redhat. Until now I've been focusing on SLES - as we've got 3 of them and only the one RHEL server. Additionally, having 65 netware servers and 29 windows servers makes it a bit hard to squeeze in time here and there. I appreciate all the help that has been offered so far.

Here is the error after running up2date from a ssh session

Your X display variable is not being set, so you cannot run any X applications. Did you remember to tunnel X sessions in your Xwin32 client running as ssh?

No, but I tried this morning and got a different error now.

You need to sort out using X first (are you sure you are running the X server on your Windows machine?). Just try getting an xterm window to work properly. Once that's working, this script, and any other X application will work.

Oh wonderful. I loaded up Xwin32 then ran the script and the screen displays. Now all I have to figure out is why the keyboard isn't working inside the Xwin32 application. Thank you so much!

Also, when logging into the X session it asks for "password" again - even though I've already authenticated via key for the ssh session. Did I miss a step?

I am not sure you want vnc. Vnc is not the most secure thing to have and many corporations do not permit it on their systems.

What you really need is:

1. The remote machine just doing its own thing at runlevel 3, but be sure the /etc/ssh/sshd_config file is enabled for forwarding "X". (Perhaps this is the reason your Xwin32 is not working?)

2. An "X" server running in the background on your desktop. I think this is what your Xwin32 is for, but I am not familiar with that product. It can be "exceed" ($$$) or Cygwin (free).

3. A client on your desktop to ssh to your target machine. This can be "putty" (free), or a Cygwin ssh inside an xterm. Exceed also provides a client, but I find it clumsy to set up.

VNC is being used in the above example only over an SSH protected link. It is as highly secure as remote access can be with current technology. In fact the VNC protocol exists only on the server side; what is transported over SSH is X (no VNC client required on the client side).

That being said, any idea why the keyboard inside the X session isn't working?

The mouse works and I can click on stuff, but typing is not functional.

That will be a function of the XWin32 application. I'm not familiar with its operation or configuration. However, the vendor's website had this note:

If that doesn't work, I suggest you contact the vendor for support.

Ok - Great. I'll try some settings - I appreciate all the help, it has been very, very accurate and on target. You rock!

A follow up on this - Our version of Xwin32 (5 something) didn't support the keyboard in this mode for some reason. The newest version does, but we decided to go with Cygwin instead.

Thanks again for all the help. I'll see if I can get it working on our SuSE Servers now :-)

Well something still isnt right. I have this set up in the following way

authorized_keys configured
Cygwin Xserver running
Paegeant running
Load Putty
Load preset for x forwarding to this server. Login as "root" by key based auth. automatically run "gui" which has been placed in /usr/bin/local
"Open" the connection, the X session doesnt start but the putty window shows this:


Yet repeating the same process, only without the "Remote command" filled in, the login goes well. Then when I am presented at the shell I type "gui" and it loads just fine.

Any ideas? (Still on the RHEL4 here)

Apparently, running with a remote command does not run as a login shell, and as a result your environment variables are not configured (in particular, your PATH). I suggest that you add the PATH to your 'gui' shell script. To find out what it needs to be, login and:

echo $PATH

Then add the result to the top of your gui script.

Macemoneta, you are again correct sir.