Re: Dropbear server exit when idle?

[Matt Johnston]

Hi Dave,

My first approach would be to run "timeout 600 dropbear -F
-E".  Established sessions won't be killed since they each
session is a forked process. That assumes "timeout" exists
on the system busybox etc.

If you want to modify the code put a check after the
select() in main_noinetd(). As-is it seems fairly specific
so mightn't be worth merging, though maybe there's a more
general way to do it.

Cheers,
Matt

On Thu, Mar 08, 2018 at 02:41:12PM +, Dave Haynes wrote:
> We have a small range of embedded linux devices used in security systems. We
> are undertaking a gradual process to harden the default security, and one of
> our first tasks has been replace the legacy telnet server with dropbear for
> diagnostic access.
> 
> We have compiled dropbear and have it running well, set up to only allow one
> session using a patch found on this list.
> 
> We are now considering if it would be worthwhile/useful to modify dropbear
> to exit after a period with no active connections. So dropbear runs at boot,
> but exits after (say) 10 minutes with no login. The devices can be remotely
> rebooted via other means, so there are no access issues for authorised
> users.
> 
> Does anyone see any reason this wouldn't be a useful approach? Anyone
> patched anything similar before we start hacking about, or any pointers
> where to start?
> 
> (We could give the system a task to terminate dropbear, but it would seem
> neater to produce a self contained solution.)
> 
> -- 
> Dave Haynes
> RF Design Consultant - Wireless Solutions Ltd.
> 

Re: Dropbear server exit when idle?

[Fabrizio Bertocci]

I don't think you should have this functionality in Dropbear. This is
specific to your use case.
You can still do it with a bash script. At boot the script can check the
/var/log/secure file to see if there is any activity on dropbear (poll the
file size every few seconds)... Reset the internal timer whenever the file
size change between poll cycles, then kill dropbear after your 10 minutes
of inactivity.

Regards,
Fabrizio

On Thu, Mar 8, 2018 at 9:41 AM, Dave Haynes 
wrote:

> We have a small range of embedded linux devices used in security systems.
> We are undertaking a gradual process to harden the default security, and
> one of our first tasks has been replace the legacy telnet server with
> dropbear for diagnostic access.
>
> We have compiled dropbear and have it running well, set up to only allow
> one session using a patch found on this list.
>
> We are now considering if it would be worthwhile/useful to modify dropbear
> to exit after a period with no active connections. So dropbear runs at
> boot, but exits after (say) 10 minutes with no login. The devices can be
> remotely rebooted via other means, so there are no access issues for
> authorised users.
>
> Does anyone see any reason this wouldn't be a useful approach? Anyone
> patched anything similar before we start hacking about, or any pointers
> where to start?
>
> (We could give the system a task to terminate dropbear, but it would seem
> neater to produce a self contained solution.)
>
> --
> Dave Haynes
> RF Design Consultant - Wireless Solutions Ltd.
>
>

Dropbear server exit when idle?

[Dave Haynes]

We have a small range of embedded linux devices used in security 
systems. We are undertaking a gradual process to harden the default 
security, and one of our first tasks has been replace the legacy telnet 
server with dropbear for diagnostic access.


We have compiled dropbear and have it running well, set up to only allow 
one session using a patch found on this list.


We are now considering if it would be worthwhile/useful to modify 
dropbear to exit after a period with no active connections. So dropbear 
runs at boot, but exits after (say) 10 minutes with no login. The 
devices can be remotely rebooted via other means, so there are no access 
issues for authorised users.


Does anyone see any reason this wouldn't be a useful approach? Anyone 
patched anything similar before we start hacking about, or any pointers 
where to start?


(We could give the system a task to terminate dropbear, but it would 
seem neater to produce a self contained solution.)


--
Dave Haynes
RF Design Consultant - Wireless Solutions Ltd.