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
On Thu, Aug 10, 2017 at 11:25 AM, Russell Warren <r...@perspexis.com> 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 ad...@example.com
> 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
> 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.