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.
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. > >
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
Running dropbear as non root daemon
configured with:
./configure --disable-pam --disable-syslog --disable-shadow \
--disable-lastlog --disable-utmp --disable-utmpx \
--disable-wtmp --disable-wtmpx --disable-loginfunc \
--disable-pututline --disable-pututxline
For Linux: no problems
For AIX:
I could not get dropbear run as a normal user with the generated config.h
After changes in sshpty.c I got it working for AIX, basicly it does now:
master = open ("/dev/ptc", O_RDWR | O_NOCTTY);
if (grantpt (master)) goto fail;
if (unlockpt (master)) goto fail;
slave_name = ptsname (master);
slave = open (slave_name, O_RDWR | O_NOCTTY);
if (termp) tcsetattr (slave, TCSAFLUSH, termp);
if (winp) ioctl (slave, TIOCSWINSZ, winp);
I also disabled the pty_release function which otherwise fails changing the
ownership back to root
After this, you can run dropbear as a normal user.
For HPux:
Compiles fine, but when running dropbear and connecting to it:
- getnameinfo() in netio.c failed lookup: address family was not
recognised
using NI_NUMERICHOST | NI_NUMERICSERV so without host_lookup
- pty error, after open on /dev/ptmx fails on grandpt even when before
that doing a signal SIGCHLD to SiG_DFL
Unable to get it working on HPux
If someone has got dropbear working on HPux, some help will be appreciated.
Hans
