background later?
Hello, I want to use dropbear just to setup port forwarding and then drop to the background, e.g. like so ssh -f -N -T -y -K 20 -I 7200 -R 2:localhost:22 remote.host.com the problem is that the code to background dropbear (in cli-session.c, line 253) is before the setup of the port forwarding (just a few lines down) so in case port forwarding setup fails, the caller of ssh has no way to find out that port forwarding failed by checking the exit code I think the code to background dropbear should be be delayed until local and remote port forwarding has succedded (esp. in -N is given) for remote connection this is somewhat tricky as the remote host has to open the ports and confirm back; so the backgrounding would need to go into cli_recv_msg_request_success() after having processed the last remote forward port in the list regards, p. -- Peter Meerwald +43-664-218 (mobile)
Problems when connecting to dropbear server running as non-root
I am trying to connect using ssh: -v -i privkey -p 7000 hans@host hostname And I get: debug1: Server accepts key: pkalg ssh-rsa blen 149 debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending command: hostname debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 [28924] Jul 15 17:40:24 Exit (hans): Couldn't change user as non-root TRACE (28924) 1373910024.524936: enter session_cleanup TRACE (28924) 1373910024.525004: enter chancleanup TRACE (28924) 1373910024.525021: channel 0 closing TRACE (28924) 1373910024.525037: enter remove_channel TRACE (28924) 1373910024.525050: channel index is 0 Dropbear is running on the host as a non-root user hans with dropbear -v -F -P 7000 and gives (small part) TRACE (28923) 1373910024.518919: enter recv_msg_channel_request 0x82ca4e8 TRACE (28923) 1373910024.518942: enter chansessionrequest TRACE (28923) 1373910024.518961: type is exec TRACE (28923) 1373910024.519100: enter sessioncommand TRACE (28923) 1373910024.519138: enter noptycommand TRACE (28923) 1373910024.519370: setnonblocking: 8 TRACE (28923) 1373910024.519411: leave setnonblocking TRACE (28923) 1373910024.519429: setnonblocking: 7 TRACE (28923) 1373910024.519451: leave setnonblocking TRACE (28923) 1373910024.519475: setnonblocking: 10 TRACE (28923) 1373910024.519497: leave setnonblocking TRACE (28924) 1373910024.519758: back to normal sigchld TRACE (28923) 1373910024.525685: enter sigchld handler TRACE (28923) 1373910024.525735: sigchld handler: pid 28924 TRACE (28923) 1373910024.525761: using lastexit TRACE (28923) 1373910024.525811: leave sigchld handler TRACE (28923) 1373910024.525836: parent side: lastexitpid is 28924 TRACE (28923) 1373910024.525857: found match for lastexitpid TRACE (28923) 1373910024.525876: leave noptycommand TRACE (28923) 1373910024.525905: leave chansessionrequest TRACE (28923) 1373910024.525925: leave recv_msg_channel_request TRACE (28923) 1373910024.525945: sesscheckclose, pid is 28924 TRACE (28923) 1373910024.525999: sesscheckclose, pid is 28924 TRACE (28923) 1373910024.526022: might send data, flushing TRACE (28923) 1373910024.526041: send data readfd TRACE (28923) 1373910024.526060: enter send_msg_channel_data TRACE (28923) 1373910024.526080: enter send_msg_channel_data isextended 0 fd 8 TRACE (28923) 1373910024.526104: maxlen 16375 TRACE (28923) 1373910024.526127: CLOSE some fd 8 TRACE (28923) 1373910024.526154: leave send_msg_channel_data: len 0 read err 4 or EOF for fd 8 TRACE (28923) 1373910024.526183: send data errfd TRACE (28923) 1373910024.526202: enter send_msg_channel_data TRACE (28923) 1373910024.526220: enter send_msg_channel_data isextended 1 fd 10 TRACE (28923) 1373910024.526245: maxlen 16371 TRACE (28923) 1373910024.526269: send_msg_channel_data: len 761 fd 10 TRACE (28923) 1373910024.526338: closing from channel, flushing out. TRACE (28923) 1373910024.526360: CLOSE some fd 10 On 2 other boxes it works perfectly, so there is something on this host which is breaking it... Anybody got a hint where to look for. thx Hans