Why dropbear starts before network

IIUIC the dropbear starts before the network. Am I right? Why it is so?

Why I care:
I set up dropbear to listen on the lan interface. The issue is that it listens only on static IPv4 address of the lan interface, not on the link-local or global IPv6 addresses. When I restarted dropbear it started to also listen on the IPv6 addresses of the lan interface. I suspect this might be caused by init order. The IPv6 addresses simply do not exits at the time of dropbear start.

Is there a simple way to restart dropbear at the moment when IPv6 is assigned to the lan interface.

Not sure if it's relevant but I have IPv6 connectivity using 6in4 tunnel.

The firewall should prevent external access, period.

If you can establish an ssh connection from outside your network using IPv6 (or IPv4 for that matter), it indicates an issue with the firewall config.

2 Likes

Thanks for the response. Just to be sure, it's recommended to have "unspecified" interface for dropbear so it listens on 0.0.0.0 and ::, right?

That is correct. Best practice is to have the service listening on all interfaces and then let the firewall allow/restrict according to your needs.

By default, the firewall allows input from the lan zone, but it rejects it from the wan zone.

Keep in mind that quite a few interface types (e.g. PPPoE, just to name one example) come up pretty late in the boot process, respectively after it has completed (maybe even hours or days, if there's an issue with the uplink or the cables being disconnected), not static ordering in the world can account for that.

If you add period to firewall ruleset it does not prevent acces.

What exactly do you mean here?

If you botch firewall you get drop bear on wan. uhttpd too.

Well, that is to be expected if you mess it up. You’ll break other things, too, although it does depend on what you do (invalid vs incorrect for your goals vs simply not recommended).

Just for reference...