Russel, 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. Regards, Fabrizio 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 > 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. > >