[omniORB] Using SSH tunnels with omniORB - HOWTO

[W T Meyer]

I recently had to use ssh tunnels to get omniORB working through a 
firewall. While it now works fine, it was a struggle to put the 
pieces together.  This note is a summary of what worked; I hope it 
makes life easier for others.

The servant machine, which I'll call jeeves, is behind a 
firewall.  The only IP port open to it is port 22, used by SSH.
A client, called wooster, needs to access jeeves, and to do this it 
needs to get the correct reference (IOR) from a name server, which 
for generality I'll say is on a third machine, auntagatha.

The problem is two-fold. First, a tunnel has to be set up into jeeves 
from a machine that is not behind a firewall. I'll call this machine 
madeline. In reality, madeline could be the same as wooster or 
auntagatha, but to be general I'll assume it is a separate machine. 
Second, the name server needs to point to the entrance of the tunnel 
instead of the port on jeeves, which is the exit from the tunnel. The 
sequence of operations is as follows.

Without tunneling:
1. The servant application is started on jeeves, which registers 
itself with the name server running on auntagatha.

2. The client application on wooster contacts the name server on 
auntagatha to get the reference (IOR) for jeeves.

3. The name server on auntagatha returns the IOR for the servant on 
jeeves to the client on wooster.

4. The client on wooster uses the IOR to contact the servant on 
jeeves to run the application.

With tunneling:
1. The user fixes the IP port for the servant on jeeves either by 
setting the 'endPoint' parameter in the omniORB configuration file or 
by setting the ORBendPoint environment variable. For example (using 
bash),'export ORBendPoint=giop:tcp::32891'.

2. The user sets up an SSH tunnel to that port from madeline. For a 
one-time connection the command is something like
'ssh -g -L 32891:madeline.domain1.edu:32891 
username at madeline.domain1.edu'. The port numbers do not necessarily 
need to be the same, but the -g option is important.

3. The servant application is started on jeeves, which registers 
itself with the name server running on auntagatha. But this 
registered IOR points to the end of the tunnel on jeeves, not to the 
publicly-available port on madeline.

4. The user needs to change the entry in the name server on 
auntagatha to point to the entrance to the tunnel on madeline. This 
is done as follows (but see below for a shell script that makes life easier)
     a. 'nameclt resolve <context.key/object.key>' (replace braketed 
item with the full context and object names used in the servant program).
     b. 'convertior <copy and paste IOR returned from step a here> 
madeline.domain1.edu 32891'
     c. 'nameclt -advanced rebind <context.key/object.key> <copy and 
paste the new IOR returned in step b here>'

The client on wooster should now be able to connect to the servant on jeeves.

Tom Meyer, Iowa State University 
(meyer at iastate.edu)                                  Version 1.0  7 Jun 06

----------------------------
Here is a quick and dirty shell script that changes the name server 
entry for you:

#!/bin/bash
#
# Name: tunnelior
#
# This script converts the entry in an omniORB name server to point to a
# different port and computer. This is useful if a servant is behind a firewall
# so clients must access it through an ssh tunnel. In this case, the 
name server
# must be changed to point to the entrance of the tunnel.
#
# usage: 'tunnelior context.key/object.key tunnelmachine.domain.edu IPPort'
#
# You must set the pivileges correctly to execute this on unix/Linux.
#
OLDIOR=`nameclt resolve $1`
NEWIOR=`convertior $OLDIOR $2 $3`
nameclt -advanced rebind $1 $NEWIOR
echo OLDIOR: $OLDIOR
echo NEWIOR: $NEWIOR
exit 0