Original instructions.

Since on the measurement machines not only system management have the Administrator password, the measurement machines are put on a different network respect to the offices' one: the meetnet. In particular you cannot move the experimental data from the measurement machine to you office via network, you cannot print and so on.

Anyway there is the possibility to make ssh tunnels through a machine to reach the office and backwards.

On the machines running windows you need:

1. standalone putty
2. standalone WinScp
3. Tight VNC server (only for the machine on the meetnet).

On other machines running Linux this software is almost installed by default. In any case, to be able to connect to display :0 of X, you should install either x11vnc or follow this instructions.

What is a ssh tunnel anyway?

Suppose you want to send from A to B some data over the internet; if you send the data plain, they can be read by someone else than the person you are willing to send them to. ssh is a program that in some ways scrambles this information you send on the internet so that only the receiver can unscramble them.

Many times it also happens that your computer A and/or B sits behind a firewall, generally unseen from the outer world. If this is the case, it will not be possible to send information from A to B directly, because the firewall will stop any connection. What you need is a computer (C) to make a “tunnel” in the firewall.

This computer (C) is visible on the internet and provides a ssh server. What you do when you make a ssh tunnel is to connect securely via ssh from A to C; then following some special rules you will be able to connect from A, via C, to B.

This connection will happen via, what is called, a port forwarding. In practice when you connect from A to C you will also tell to C that you want to connect to B, and in particular that all the information you (A) send on a particular port (i.e. 8080) you want C to send to B on another (specified, i.e. 80) port.

On a teminal window it will appear as a command:

YourUsernameOnA@A:$ ssh -L 8080:B:80 YourUsernameOnC@C

so that in this case all the information you will broadcast from local port (hence -L) 8080 of A will be sent by C to port 80 of B.

So, now you just made the hole in the wall, or the tunnel in the firewall. To connect from A to B via tunnel on C (forwarding the local port 8080 to remote 80) you just have to start the program (on A) that wants to connect to B, telling to the program to connect to A on localport 8080.

Port 80 is the http port, so in the example above, the http connection to B from A via tunnel on C will be done asking your web browser to connect to http://localhost:8080

Automagically, any connection on local port 8080 will be encripted, sent to C, unencripted and sent to B on port 80, (where hopefully you have a web server listening on port 80) and viceversa.

Anyway if it is easy to connect via ssh tunnel from machine on the meetnet (A) to the office's one (B), it appears that the measurement machine is anyway unreachable from the office via the same tunnel. So what now?

With ssh it is possible to forward remote ports also. What does it mean?

Right now I can connect from A to B via tunnel on C, but not the other way around from B to A via tunnel on C. With the local port forwarding I manage to transfer via scp the data from measurement computer A to my computer in the office B. But if I want to control the measurement computer using a VNC server running on it I cannot, because from B, making the proper tunnel the measurement computer A is unvisible.

Here it comes in the REMOTE port forwarding. Let's suppose that your computer A runs some service on some port (i.e. VNC server on port 5900) and is not reachable by B via tunnel on C. What we do now is to establish a ssh connection from A to C, instructing C that every connection that it receives on a specified port (of C, hence remote) must be encripted and sent to A on some other specified port (i.e. remote port 25900, and port 5900 on A).

On a terminal would be like: YourUsernameOnA@A:$ssh -R 25900:A.IP.number:5900 YourUsernameOnC@C

where A.IP.number is the IP number of A.

In the meanwhile from B we start a local port forwarding, to tunnel via C, and use the port that we remote forwarded:

YourUsernameOnB@B:$ssh -L 25901:localhost:25900 YourUsernameOnC@C

so that the connection to localhost on port 25901 will be encripted and sent to C on port 25900.

Now C knows what it has to do: it receives a remote port forwarding from A, and a temptative of use the same port from B: it will establish 2 encripted connections, one with A and the other with B.

In our example, A has a VNC service on port 5900 and makes a remote port forwarding (on port 25900). B tries to connect to A via tunnel through C forwarding a local port (25901) asking to connect to outbound port 25900 of C, resulting in an encripted connection to A on port 5900.

Let's resume:

1. On A start a remote port forward from A to C, on port REMOTEPORT
2. On B start a local port forward from A to C on LOCALPORT to REMOTEPORT
3. On B start a client of the service runnning on A, as if the service runs on A port LOCALPORT.

Well, that's it!