In a fashion amazingly similar to that above. First keep in mind that what you
really need to do is to pass the DISPLAY created by ssh on gate further into
the Research Network.
ssh gate.csd.uwo.ca /usr/local/bin/xrsh quarrel.syslab.csd.uwo.ca xterm -ls
The xrsh script runs rsh for you after setting up and passing the DISPLAY
variable through to the remote end. You might want to add the -n option
to ssh and background the entire command. Then you won't have to worry about ssh
on your local machine hogging a window.
Alternatively you can use "straight" rsh as long as the X application you
are trying to run has a -display (or something similar) option. For
ssh gate.csd.uwo.ca rsh algernon /usr/local/bin/acroread -display '$DISPLAY'
In this case the single quotes around the $DISPLAY are
If the machine you are trying to get to does not support rsh (without passords),
you're going to have to play even more games. Like this:
ssh gate.csd.uwo.ca /usr/local/bin/ssh quarrel.syslab.csd.uwo.ca xterm -ls
which should work. Please note that the /usr/local/bin business is very likely
necessary. And you do not need the -t because xrsh (or a second ssh) will
set up the pty that you need.
On some systems, you will need to add a -X (or similar) option
in order to enable the tunnelling of X traffic. This is known to be true for
some MacOS X systems. Read your local ssh man page.
ssh -C -f -N -L localport:internalhost:internalport gate.csd.uwo.ca
Whew, that's ugly. No it's not, it's just complex. What it's doing is
forwarding (bidirectionally) a port from a Research Network machine out
through gate and back to your home computer.
The -C tells it not to do compression. Trust me.
The -f tells it to automatically background itself after any
The -N tells it not to run a remote command. With this, all it does is
forward the port. Please note that this option is not available
with some versions of ssh. It also means that you'll need to remember to kill
this ssh process once you no longer need it.
The -L localport:internalhost:internalport is the magic. You replace
localport with the port number on your local machine where you
wish the remote port to magically appear. You replace internalhost with
the hostname of the research network machine on which your service is running.
And you replace internalport with the port on the internal machine on
which the service is available.
Here's a more concrete example. If one is running a VNC Server on
ostracod.csd.uwo.ca at port 5901, then one can get at it from home by typing
% ssh -C -f -N -L 5901:ostracod.csd.uwo.ca:5901 gate.csd.uwo.ca
% vncviewer localhost:1
Once the ssh command backgrounds (after asking for a password if necessary),
one types the vncviewer command at the next prompt. Please notice that
one is telling vncviewer to look on the local host for the VNC server.
It will "appear" to be there because ssh is forwarding ostracod's VNC port to
the local host.