dropbear fully support tunneling. Both local (with -L) and reverse (with
-R). I have been using for quite some time now.
If you expect your local port (63333) to be reached from other machines,
make sure to use the -g option as well.

I think your problem is on the server side, on the ssh server that refuses
the tunnel.


On Thu, Aug 10, 2017 at 11:25 AM, Russell Warren <> wrote:

> Does dropbear support tunnelling? I can't find any references for it, but
> may be searching for the wrong keywords. "tunnel" exists only once in the
> source tree, for example.
> My expectation is that it does not support it, but would like to confirm.
> I'm asking because, when I tried to set up a tunnel it did not work.  Here
> is what failed:
> I tried to set up the tunnel on my client like this:
>     ssh -p 1018 -v -v -v -L 63333:localhost:5433
> and tried to connect through it with this (also on the client):
>     psql -h localhost -p 63333
> the initial connection gives this output:
>     debug1: Connection to port 63333 forwarding to localhost port 5433
> requested.
>     debug2: fd 9 setting TCP_NODELAY
>     debug2: fd 9 setting O_NONBLOCK
>     debug3: fd 9 is O_NONBLOCK
>     debug1: channel 3: new [direct-tcpip]
>     channel 3: *open failed: administratively prohibited*:
>     debug2: channel 3: zombie
>     debug2: channel 3: garbage collecting
>     debug1: channel 3: free: direct-tcpip: listening port 63333 for
> localhost port 5433, connect from ::1 port 57636 to ::1 port 63333,
> nchannels 4
>     debug3: channel 3: status: The following connections are open:
>       #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
> If it matters, the end intent here is actually to use ssh tunneling to
> access postgres running on the server with dropbear (usign standard tools,
> like pgadmin3, which presumably expect standard tunneling implementations).
> The above tunnel attempt was while trying to debug connection failures with
> these tools.

Reply via email to