I should have asked this question here...this is where the ubergeeks hide from the light.

I have an Ensim box...Ensim may get the axe soon, we'll see, for now I'll give it a chance.

So, I wanna login via ssh and run Xapps. I do this all the time on my boxes on my local lan.

I posted the details of what I want in this thread:

http://forum.rackshack.net/showthread.php?...&threadid=11956

Could I get the assistance of a wizard?

Maybe a checklist of the necessary rpms for this to happen?

Thanks.

My best guess, from looking at the RedHat Files. I've done this before. You basically only need XFree86-libs and XFree86 to get X apps to run, but then you need to deal with it's dpendendecies (libICE, libX11, libXpm), and hey you wouldn't be able to do much with just that. This should get the libraries installed:

rpm -ihv XFree86-
4.1.0-3.i386.rpm XFree86-libs-4.1.0-3.i386.rpm XFree86-xfs-4.1.0-3.i386.rpm chkf
ontpath-1.9.5-2.i386.rpm Mesa-3.4.2-7.i386.rpm Xaw3d-1.5-10.i386.rpm

Here's the list I abreviated from the RPM list on the CDROM (./RedHat/base/comps). It should get the font server working, and include some tools (xload, xeyes, xlogo, etc...), and a window manager.

XFree86
XFree86-75dpi-fonts
XFree86-100dpi-fonts
XFree86-ISO8859-15-100dpi-fonts
XFree86-ISO8859-15-75dpi-fonts
ttfonts
XFree86-libs
XFree86-tools
XFree86-twm
XFree86-xdm
xinitrc
xloadimage
XFree86-xfs
chkfontpath
freetype

I'm sure dependencies will fail, and it's up to you to make them feel loved.

Thanks man, thats a good list. I installed almost all of those yesterday. I skpped a couple, but I don't think it would matter. I didn't get any dep errors.

I am a step closer to making this work, I now can get the display variable set. And now I get an error message when I log in with the -X flag set that is not there without it. I posted the error message I'm getting now in the other thread...link above.

Wow... that's a "good" error meassge. I'm guessing it has something to do with the step ssh takes to set Xauthority on the local machine. What does it tell you when you try to run an X app? What is the DISPLAY variable set to?

Well, here how it stands now.

I was trying to get up2date to run in X cause I like using the gui version of it. There was a large case of user error preventing me from getting this to work. Apparently there are 4 rpms that need to be installed on a system to make up2date run under X.

rhn_register-2.8.27-1.7.2.i386.rpm
rhn_register-gnome-2.8.27-1.7.2.i386.rpm

up2date-2.8.39-1.7.2.i386.rpm
up2date-gnome-2.8.39-1.7.2.i386.rpm

I was lacking the -gnome packages...so there was no way up2date was gonna run in X, even if I had it configured right.

So, once I got those installed, along with a crapload of other rpms to solve dependency issues, I was able to get up2date to run in a remote X session. I updated my system a bunch and will now sleepa little better knowing those gaping security holes are patched.

It still doesn't work through ssh.

the error I get with ssh is :



$DISPLAY is set to:

localhost:10.0

I don't know exactly what this is all about and I'm not sure I care at this point. I think you are on the right track about Xauthorty being screwed somehow. I just don't know exactly where to search in my system to get a detailed log of whats going wrong. The X logs in /va/log don't help, the messages log doesn't help. I can do the remote X session when I have to. I might work on it some more in a few days.

Thanks for trying to help man.

I think what you want to do is set your DISPLAY environment variable to ip-of-computer-running-X-server:0 (or ip:0.0? Something like that), with:

DISPLAY=home.computers.ip:0 && export DISPLAY

then, on the machine running the X server (your home machine), with X11 running run this in an xterm..

xhost

What this does is make all X apps running on the server use your home machine as the display, and then sets the X server on your home machine to accept connections from your server.

From there you can try "xterm" on the server and see what pops up. If it says something about not being able to connect, and you think the DISPLAY variable isn't right, you can always do..

xterm -display ip-of-home-machine:0

Oh.. and keep in mind that unless you have an extremely fast connection to Rackshack, this is going to be crazy slow at displaying graphics and whatnot.

Also, as you may or may not already know, you must be running X (or an X server) already on your home machine in order to use X apps off of your RS server (or any remote machine).

I hope some of this is useful.

Thanks for the reply man, I actually got it working a couple days ago...sorta.

What you described is more to establish a remote X session. What I am trying to do is to tunnel an X app through ssh. There is a subtle difference...which is a huge pain in the @#!@#!@#!.

The speed actually is pretty good. I have a DSL line and get acceptable performance doing remote X.

On my local machine I am of course running an X server when in linux, and when forced to use windows I am running the cygwin tools to provide a local X server for the apps to use. Works great. I use this setup all the time to connect to unix machines on my lan.

Believe it or not, all of the following rpms were needed to get a remote X session in which I could run gnome apps running.

audiofile-0.2.1-2.i386.rpm
esound-0.2.22-5.i386.rpm
gdk-pixbuf-0.11.0-8.i386.rpm
gnome-libs-1.2.13-16.i386.rpm
gtk+-1.2.10-11.i386.rpm
imlib-1.9.13-3.7.x.i386.rpm
libglade-0.16-4.i386.rpm
libungif-4.1.0-9.i386.rpm
libxml-1.8.14-2.i386.rpm
Mesa-3.4.2-10.i386.rpm
ORBit-0.5.8-4.i386.rpm
pygnome-1.4.1-3.i386.rpm
pygnome-libglade-1.4.1-3.i386.rpm
pygtk-0.6.8-3.i386.rpm
pygtk-libglade-0.6.8-3.i386.rpm
python-popt-0.8.8-7.x.2.i386.rpm
rhn_register-2.8.27-1.7.2.i386.rpm
rhn_register-gnome-2.8.27-1.7.2.i386.rpm
switchdesk-3.9.7-1.i386.rpm
up2date-2.8.39-1.7.2.i386.rpm
up2date-gnome-2.8.39-1.7.2.i386.rpm
usermode-1.46-1.i386.rpm
Xaw3d-1.5-10.i386.rpm
Xconfigurator-4.9.39-2.i386.rpm
XFree86-4.1.0-25.i386.rpm
XFree86-75dpi-fonts-4.1.0-25.i386.rpm
XFree86-twm-4.1.0-25.i386.rpm
XFree86-xdm-4.1.0-25.i386.rpm
XFree86-xfs-4.1.0-25.i386.rpm
xinitrc-3.20-1.noarch.rpm

All can be found at rpmfind.net.

Running X remotely is HUGELY insecure WITHOUT tunneling thru SSH. This is as bad as using telnet and logging in as root. If you're doing up2date over this link you have a ROOT session running unencrypted and potentially open to sniffing and/or hijacking. It's not worth the risk...

Definitely shutdown this service unless you want to be cracked pronto!

Double check that netstat -a doesn't show port 6000 listening to the world.

Real men don't put X on a remote server, or probably any server for that matter.


-N

One could run vnc... or xdmcp

Thanks for the security warning, I suppose many of the readers of this thread could benefit from that.

Running a remote X session was just a part of my testing to get X forwarding through ssh working.

Remote X is safe to use on a lan, which is where I use it primarily. I do not plan to run remote X sessions on my server and in fact disabled the possibility of that after my test.

I ran up2date in a remote Xsession in desperation. My new box had several packages which needed to be upgraded. I believe that the three virtues that make a good perl pogrammer also make a good sysadmin. Laziness and impatience motivated me to use up2date, rather than do it manually. Hubris convinced me that I could do it without getting cracked (I changed the passwords afterwards).


And to greyboy....real men run X remotely cause its cool.

Try screen on for size, it's nice.. and runs in ssh.

XDMCP uses UDP making it incredibly easy to spoof the source address of packets (since there is no TCP/ACK handshaking). Its also unencrypted as well.

VNC is probably more secure but only the intial login is encrypted after that the session is still in the clear.

Each of these can also be tunneled thru SSH which is really the ONLY secure solution. SSH also can add compression which might boost performance a bit on a fast machine...

xdmcp tunneled through ssh might be worth looking into then, since it will process most of it on the client side, as compared to vnc, which is server side. If you must use vnc, try tightvnc, which processes mouse movements on the client side for the most part.


How does one tunnel these through ssh?

This HOWTO would get you started:
http://www.tldp.org/HOWTO/XDMCP-HOWTO/

This advice of course comes without any warranty

I'd suggest you try it first with a local linux machine...