[FreeNX-kNX] nxtunnel rewritten

[Neal H. Walfield]

Hi All,

I downloaded the Free NX packages from http://www.kalyxo.org/debian/
and once I figured out how to use NX was really impressed by what it
had to offer.  If it hadn't been for the scripts in the
nxtunnel-client and nxtunnel-server packages, i would have just
abondoned it.  As they were rather sparse on functionality (and
scarily insecure), I rewrote them yesterday.  The result is not
perfect but I think it is quite functional.  I have attached the to do
list.  I'd appreciate any feedback (please cc me on any list replies).
You can find it at: http://web.walfield.org/pub/people/neal/nxtunnel/ .

Thanks,
Neal

$ nxtunnel --help
Usage: nxtunnel [LOGIN@]HOST [OPTION] COMMAND [PARAMETERS...]
Connect using ssh to HOST as LOGIN.  Tunnel an X connection using NX
compression via the encrypted link and run COMMAND.

  -d DISPLAY             X server to use.
  -g XxY+X+Y             Specify the geometry of the root window (only
                         useful if --root is also specified).
  -p PORT                Connect to an alternate ssh port.
  -r, --root             Set up a rooted window.  Use when running a
  -window
                          manager.  If this option is not specified,
  -you
                          won't get many of the speed ups that NX
  -offers.
                          Cf. http://www.nomachine.com/faq.php#12
  -V, --verbose          Be verbose.

  --help                 Display this message.
  --version              Display the version.

Examples:
  Create a KDE desktop environment:
    # nxtunnel --root -g900x700 user at host startkde
  Start an xterm in a floating window:
    # nxtunnel user at host xterm
  Start a shell (similar to a plain ssh session);
    # nxtunnel user at host bash

Report bugs to <neal at walfield.org>.

The todo (and caveat) list:

 - If no application argument is given, run a login shell.
 - The real authentication cookie is sent to the server we should 
   generate a unique cookie and have a filter in place to transform
   it.  (This is similar to how ssh forwards X connections.)
 - Quoting the command line is definately broken (e.g. try:
     nxtunnel host echo 'foo    bar'
   This yields "foo bar" and not "foo   bar" as is likely expected.
 - Get nxproxy and nxagent into terse mode!  Currently, we filter out
   all info: lines but still, it would be nice to get rid of the banners
   as well and only have error messages show up.
 - Check to make sure that grep and sed support --line-buffered and
   --unbuffered respectively.
 - nxproxy/nxagent work in the following manner: nxproxy lives on the
   X server (i.e. the local computer).  It connects to the the nxagent
   which lives on the X client (the remote application server).  We want
   the X connection to be encrypted.  In order to do this, we must tunnel
   the link between nxproxy and nxclient in the ssh connection.  The
   problem, however, is that we must choose a port to forward to before
   we are on the remote host but we cannot know what ports are available
   on the remote host.  If the port that we choose is already in use,
   nxagent will be unable to bind to it.

   The solution is to be able to choose the port to forward to after
   the connection is made.  But how to we do an upcall to the ssh
   machinery to create the link?  An extension could be made to ssh
   that will allocate a port of the remote side if none is given and
   store the mappings in a variable, e.g. SSH_PORT_FORWARD with
   the form on the command line, i.e. "-Lport:host:port ...".  I must
   ask the openssh people about this.

   A possible hack is to forward multiple ports and hope that at
   least one of them will work.

   Currently, we encounter this limitation *way* too often.
 - Major timing issue problem: nxagent tried to connect to the
   forwarded port.  If the connection hasn't been made the ssh
   fails to forward the port at all and nxagent fails.  If you
   use a password and have to enter it on each connection, you
   will notice a fair number of

      channel 2: open failed: connect failed: Connection refused
      nxproxy: Error: Remote NX proxy closed the connection.
      nxproxy: Error: Please check your authorization credentials.

   This is not an authorization problem.  The port has just not
   been forwarded.  (List the connections using ~# in ssh).
   This issue basically disappears as soon as you start using
   ssh-agent.

   One way to fix this would be to start nxagent after ssh has
   connected.  (e.g. using ssh -f to background ssh after a
   connection has been established.)  The problem is that we can't
   use CLI applications (e.g. running bash).  Which sucks as
   I want this to be my ssh replacement.