Paths starting with / are absolute paths; to give a relative path, use a path without the leading slash:Also of interest are the special directories . and ..; . refers to the current directory, so changes to your current directory; ordinarily rather useless. But suppose you're in /usr/bin, and want to go to /usr/share:There's a lot of addresses and ports flipping around here, so pay close attention:
Warm colors designate data interpreted by ssh; cool colors designate data interpreted by sshd. (The ssh server, running on the machine you want to control.)

Code:

ssh -Llocalport:forwardhost:forwardport user@remotehost

ssh makes a connection to remotehost[/code], telling it your username is user (this controls what password to accept, and what UID processes you run will be, if you're doing that...). It sets itself up listening on localport, and forwards any connections made there through a tunnel to the remote machine, which will then try to make a connection to forwardport on forwardhost.
Now you can skip this paragraph, if you don't care; it's just an example of how you might use some of these options; stuff relevant to the specific case under consideration is later: Suppose you have a LAN behind a NAT, with one computer exposed as a DMZ; further suppose that you (from out in the internet somewhere) want to access one of the other machines on the LAN. You can't get to it directly, but you can ssh into the DMZ. You can do

Code:

ssh -Llocalport:insecure.host.lan:forwardport DMZlogin@NAT's.WAN.side.IP

Now, even though insecure.host.lan is so unsecure we daren't expose it, we can still get at it through the industrial strength DMZ. And we could even be making the connections to the machine running ssh from some other machine. That's why this is so complicated; each port forwarding involves 4 machines. It just happens, in our simple case of VNC tunneling, one machine is being both the connection client and one tunnel endpoint, and one machine is being both the other endpoint and the eventual connection server

So to forward traffic from port 5901 (local) to 5900 on your XP box, you want:That covers making the tunnel.
Whether the VNC connection goes through the tunnel depends on what you specify as the server in VNC Viewer.
This is much, much simpler, because VNC only deals with two machines; the client and the server. You use .
servername is the server to connect to; since we want to connect to the near end of the tunnel, that'll be 127.0.0.1
Now the standard way of specifying a VNC display is with the display number; these start at 0. The actual port numbers used are allocated starting from 5900 for display 0, and go up as expected. But, if you put in a number like 5901 for the display, it's "helpful" enough to know that you couldn't mean display 5901, connecting on port 5900+5901 = port 11801, but must have meant port 5901. I don't remember at what cutoff it considers a number to be large; but that doesn't really matter. Since we just opened a tunnel at port 5901, subtract 5900, and it's display 1. So we need to tell VNC Viewer to connect to 127.0.0.1:1; 127.0.0.1:5901 would work, too, but is bad form.

As in my previous post, you can wrap it all up with this shell script:
The -f tells ssh to drop to the background so we can start the next command; the sleep 10 is a command for the remote host; if you don't specify anything, it gives a shell, but this way it just waits 10 seconds and disconnects. That way, you don't have to manually log out when you're done with VNC.