View Single Post
jldiaz's Avatar
Posts: 48 | Thanked: 40 times | Joined on Apr 2008 @ Spain
#25
Let's try again, this way with a picture (at the end of the post). For the sake of this example, assume that the IP of your XP box is 145.32.79.12, and the IP of your Nokia is 201.24.5.32 (you don't need this information, but anyway).

You run in XP the ssh server (called sshd) and the VNC server. Each of these processes opens a port with a well-known number. For sshd, the port number is 22, for VNC it is 5900 (plus the number of the display, but let us assume that it is zero).

So, your windows machine has two open ports. If you have no firewalls, both ports would be accesible from the outside. From any computer in the world, anyone could connect to your port 22 for a ssh sesion (he would require a ssh client, such as the ssh in the nokia), or to your port 5900 for a VNC session (he would require a VNC client).

You can estabilsh both connections from your nokia. Using ssh, you can issue the command: ssh user@145.32.79.12, and this will make a connection between the ssh process in your nokia, and the port 22 of your XP machine (in which the sshd server is listening). You will be prompted for a password and then you will have access to a command-line shell which is run in your XP machine. You can control your XP machine via this shell. If you prefer to control it via its graphical interface, you can launch your VNC client and specifying the host 145.32.79.12:0 This will connect your VNC client in your nokia with the port 5900 in your XP (in which the VNC server is listening). However, doing so, the data sent through the VNC protocol is unencrypted.

But ssh has another functionality (in addition to allows us to access to a remote shell as described above). It can also create a "secure tunnel", thanks to his ability of forwarding ports. In order to use this functionality, the -L swicth is used. This switch requires three parameters (separated by colons):
  • The number of a local port; the ssh client will listen in this port (in the nokia), and any data received through this port is sent to the other end of the ssh conection (to the sshd process).
  • The name (or IP) of a machine (which in our case is the XP machine, but in general it could be a third machine)
  • A second port number, (which exists in the machine specified in the previous argument). The sshd process which receives the "tunneled" data from ssh, forwards this data to the machine and port specified here.

That is, if, in machine A the following command is issued:

me@machineA:~$ ssh -L P1:machineC:P2 user@machineB

Then, any traffic coming to port P1 in machineA would be redirected to the sshd process in machineB, which, in turn, will forward it to port P2 of machineC. The traffic between A and B is encrypted, but between B and C is not. In our case, B and C are both the WindowsXP server, and A is the nokia.

Now, once the tunnel is set up, when we launch the VNC client in the nokia, instead of specifying 145.32.79.12:0 has host:display, whe specify localhosts:1, as if a vncserver were running in the nokia in the display 1. Of course, there is not such a server. However, VNC is fooled in thinking this, so it will try to connect to port 5901 of the Nokia. In this port ssh is listening (due to the -L option), and this petition is forwaded to sshd in the XP box, which in turn translates it into a connection to the port 5900 of the XP box. Here is the VNC server, so the VNC client finds indeed an VNC server, only that (without he knowing it), it is not in the nokia, at localhost. The VNC client only talks with the local process ssh, which he takes for a VNC server.

Similarly, from the viewpoint of the VNC server in XP, a connection from a client has been received, but this connection was coming from the own XP machine (sshd process), so VNC is "thinking" that the client is running in localhost (the XP). The VNC server knows nothing about the existence of the Nokia client. The VNC server only "talks" with the local process sshd, which he takes for a VNC client.

This way, the ssh protocol is fooling the two ends of the comunication, pretending that he is the other end. The picture should make this clear. I hope so :-)

__________________
--ル Diaz
 

The Following 6 Users Say Thank You to jldiaz For This Useful Post: