No, it does not. The firewall prevents access to the SSH port by default. If you're testing with your WAN IP from the internal network, it is still going to work. Please test again from a different internet connection and you will see that it's not possible to log in.
You right. It is protected by firewall. But for some cases you want to open your dropbear to internet. And better if dropbear will prevent password logins from internet by default but not from local network.
Well, what do we say?
Linux won’t stop the operator from doing really crazy things since you are expected to know what you are doing, you need Windows or Apple for that kind of user operational idea security.
The best security for this, if it is really really necessary is to use another port than 22 since every DoS attack port scanner out there will test port 22 first.
I've just checked it out. It is indeed working for simple configuration. But fails (allowing password login from wan) if here is public IP on lan interface IPv4 or IPv6. So, good temporary solution. But it lack same flexibility as OpenSSH does (with 'match address' configh where you can allow only unroutable (local link) password auth).
Luci have big yellow warning that password is not set and system is not secure
user coming from snapshot build
no luci
they use ssh
the very first thing showed is that the system doesn't have a password and the
system is not secure.
In both scenario if the user doesn't set a password is ignoring various warning (that are not removed/can be ignored... they are there as long as a password is not set) and it's own fault.
On top of this by default lan is not bridged to lan and anything from wan is rejected.
At max we can consider enforcing setting a password by not permitting further action without setting a password first or even better suggest using private key and disable password login.
This IMHO should be a correct suggestion but again... it's just to make it more difficult for stupid user that have no idea of any concept of security to have things with no password.
Also dropbear close the connection after 5 wrong password if i'm not wrong.
(so in short to open the ssh on the wan you either have to login with ssh or use luci and you would ignore the warning in both case)
Following default security policy from desktop linux installation (debian in my case, which is disallow remote / network login with no password by default) is good practice. I can be sure if I drop password for any account on my system, it automatically become local account only. But openwrt would make no sense in that case, since it has only network access. But we still can choice between lan / wan options.
Openwrt by default should follow it as well. At least having config suggested by eduperez, that would make sense, since password or no password authorization from internet (routed address) is pointless. Second option (more secure) having my patch + dropbear option "lan pass auth only: on" allowing only pass auth from lan (unroutable address).
BTW do you know better (openwrt most likely already has it) implementation for IP4/6 compare function? Mine not optimal.
I guess you missing my point I explained many times: firewall not going to work here, since firewall does not analyze traffic it can't control auth options based on password or public key. It only can block or allow connections.
That is true... but the idea is that it does indeed block the connections, so it is setting up a secure default condition and needs no further modification to remain secure, just like your debian box's 'local only' policy.
Really, the best way to open your router for remote administration is via a VPN. You can setup Wireguard (or OpenVPN or other protocols) and then you have a means of securely connecting to your router from anywhere. This way you're not opening the dropbear server itself to the internet.
By security you mean block everything which can possibily be unsecure. That is default for openwrt. Fine. I got you point, I'm not arguing with that. Now I need more open and secure solution.