SSH Tunneling On Demand

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have seen one or two posts regarding this topic but none have
produced results.  I am looking to create an ssh tunnel to forward
unsecure traffic over.  There is no way within the application to
script a ssh tunnel to establish prior to communication.  The one
promising "solution" involved using inetd to solve the problem.  I have
adapted this to use xinetd since it is more main stream now.

Here is what has been done thus far:

Configured and tested ssh with RSA authentication so I'm not prompted
for a password.

Add to:
ssh-nessus   20000/tcp


service ssh-smtp
        flags           = REUSE
        protocol        = tcp
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/ssh
        server_args     = -T -v root@ -L 20000:localhost:1241
        disable         = no

When I telnet localhost 20000 the ssh tunnel establishes but will fails
to setup the tunnel.  Reason for this is xinetd is already listening to
this port and ssh can't bind to it.

The question:
Is it possible to identify the socket that is created when xinetd
accepts the connection?  Can we pass this socket to ssh for use in
setting up the tunnel?  Or is there a better way to go about this?

I have seen a couple comments where perl was used with the Net::libcap
library to listen for the communication when it tried to establish, if
the tunnel wasn't up, it would bring it up.  However, if there was
congestion on the link, packets would be lost and there would be a
possibility of missing the trigger to establish the ssh tunnel.  I
would preffer not do go about setting the on-demand tunnel up this way.

Any sugestions would be greatly appreciated.

Re: SSH Tunneling On Demand

Quoted text here. Click to load it
Quoted text here. Click to load it

The problem is port 20000 gets connected to the stdin/stdout of the ssh
process and can't be reused for the port forward.

If you have connect[1] (or netcat) on the remote system then you can change
that xinetd setup to:

server_args     = root@ connect localhost 1241

This should work fine, the only thing to watch for is that the connect/nc
processes don't get left hanging aroung (some versions of netcat don't
check for EOF on their stdin and will hang around as orphans).


Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: SSH Tunneling On Demand

Quoted text here. Click to load it

1. Run socat on the other side.  Skip the tunnel.

2. It might be easier to establish (and maintain - autossh) the tunnel
separately and then just use SOCKS (socat again) through xinetd.

3. OpenVPN sure is handy.


Site Timeline