[PATCH] Tunneling in reverse

[Steve Fink]

I need to add some sort of remote access capability to an appliance we
will be installing in the field, and httptunnel is perfect for the
purpose -- except it's backwards.

We can only rely on the unit being able to reach us through its
firewall, not vice versa. So far, so good -- that is the standard
configuration of httptunnel. However, we need to be able to SSH in to
the unit, and we don't want the units to be able to automatically log
into us. (I have encountered this in a similar situation at a previous
company, but there it was ok for the units to be able to log in
automatically. So I just had them contact my colo server and forward
their sshd ports to the colo. Not an option this time.)

The attached patch is my initial pass at reversing the roles of the
client and server with respect to the tunneled channel of
communication. It adds a -p (--pass-to) flag to htc and a -L
(--listen-port) flag to hts. Thus, you can do:

  headquarters> hts --listen-port=9999 9000
  appliance> htc --pass-to=22 headquarters:9000
  headquarters> ssh -p 9999 localhost

With these options, hts will first wait until it accepts a connection
on its HTTP tunnel port. After it receives the connection, it will set
up a server on its listen-port and wait for another connection. Only
after both connections are established will it pass data back and
forth. If you attempt to connect to the forwarding port before the
tunnel is set up, the connection will simply be refused (because
nobody is listening). That seemed simpler than being fancy and
listening on both, essentially queueing up connection attempts. (And I
didn't want to spend more than a couple of hours on this!)

The option names kinda suck, but I didn't want to think very hard.

Somebody please tell me if I'm being an idiot and there's an obvious
alternative I'm missing that doesn't require source changes.

httptunnel-3.3-reversible.patch
Description: Text document