Re: Tunnelling support?
See https://unix.stackexchange.com/questions/14160/ssh-tunneling-error-channel-1-open-failed-administratively-prohibited-open When you get your tunnel working, you may also want to use -o ExitOnForwardFailure=yes option to make dbclient exit if tunnel is not created, otherwise connection may left hanging in case of forwarding error 10.08.2017, 18:54, "Fabrizio Bertocci" : > 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 (6) 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 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 6:localhost:5433 ad...@example.com >> >> and tried to connect through it with this (also on the client): >> >> psql -h localhost -p 6 >> >> the initial connection gives this output: >> >> debug1: Connection to port 6 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 6 for >> localhost port 5433, connect from ::1 port 57636 to ::1 port 6, >> 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. -- Regards, Konstantin
Re: Tunnelling support?
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 (6) 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 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 6:localhost:5433 ad...@example.com > > and tried to connect through it with this (also on the client): > > psql -h localhost -p 6 > > the initial connection gives this output: > > debug1: Connection to port 6 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 6 for > localhost port 5433, connect from ::1 port 57636 to ::1 port 6, > 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. > >
Tunnelling support?
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 6:localhost:5433 ad...@example.com and tried to connect through it with this (also on the client): psql -h localhost -p 6 the initial connection gives this output: debug1: Connection to port 6 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 6 for localhost port 5433, connect from ::1 port 57636 to ::1 port 6, 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.