On Jun 1, 12:14pm,
foodog@uswest.net wrote:
> from home:
> ssh workbox
> <login>
> netscape &
> <read mail, etc.>
>
> Since netscape's running on the remote machine (workbox) it needs
> to have a path to send the X output to my home subnet. It's not a
> matter of not having authorization to connect to my home machine's
> X server, I gave it that with xhost.
When you log into the remote machine (workbox), you should be
able to do "echo $DISPLAY" and see something like
workbox:10.0
By default, ssh has (or should) create the necessary tunnels for you.
It also sets the DISPLAY environment variable and runs xauth for you.
If this is not happening, you should check your ssh2 options to
see how to set this up. (I only use ssh1.) It could also be
that your sysadmins have configured the ssh daemon on the remote
machine so that X forwarding is disabled. You'll want to take
a look at the global configuration file to see if that's the
case.
Many of the remote machines that I log into have X forwarding
disabled. (This decision is several years old and was made (I think)
to conserve bandwidth to the corporate machines.) Tunneling in
general is not disabled. I have tried (with limited success) to
create X11 tunnels by hand. I have had much better luck at tunneling
VNC though. (See
http://www.uk.research.att.com/vnc/.)
VNC may prove to be a better solution for you anyway. At my previous
employer, I found that the application we were developing was too
network intensive to start up over a remote X session. (Something
would timeout in the process of starting up.) Also, if the network
connection went down for some reason, I'd frequently lose my ssh
session. This can be really annoying if you're reading mail and
your mail reader loses all of its state regarding the messages that
you've read/saved so far, etc.
OTOH, with VNC, the X server is actually running on the remote
machine. (Normally, the X server is the machine that you're sitting
in front of.) The VNC protocol is used to transfer screen updates
from the remote machine to your local vncviewer and vice versa for
keyboard events and mouse movement. This means that you can have
persistent sessions that you can check from a variety of locations.
Also, if the connection between vncviewer and vncserver (which
contains the X server with your session) is severed, you don't
lose your entire state. You can log back into the session again
from other locations. And finally, VNC is much friendlier to
low bandwith connections.
VNC has some other neat features including the ability to connect
more than one vncviewer to a vncserver. This could be handy for
demonstrating an application to someone who is remote from you.
Also, the viewers run on a variety of different platforms including
linux, windows, and macos. There is also a Java client so that you
can run a viewer from a web browser. And, surprisingly enough,
there's also a Palm client.
Anyhow, I've had a lot of success with setting up tunnels for VNC.
The instructions for doing so are in the FAQ on the VNC pages. Let
me know if you have trouble finding it.
Kevin
(text/plain)