[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
***@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
(***@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