Lets see:
“The problem with adding a user and disabling root login is with an upgrade it’s quite possible your added user account will be removed and root login re-enabled.”
To me that sounds like: “…said the update process can’t handle root being locked down…”
The user in question specifically asked a question about how to access the CLI of the router. It was thus appropriate to make a case for how to properly secure the access to said CLI. The user did this to learn something new - which is always a positive thing - and in that respect providing suggestion on how to properly secure CLI is even more good information.
“…so you want turris to create an “admin” user, with some “admin” password …”
Nope I didn’t say that. I provided best practice that is mirrored by the generic OpenWRT recommendations for hardening on how to create a specific user to not expose the ROOT account for SSH login.
However now that you breached the topic - yes, I believe that the Omnia guys should not encourage the usage of the ROOT account the way they do. The Omnia project is, at least for a large part, about security and closing down attack vectors. The usage of the ROOT account for SSH login (and even the LuCI web page) is one of those.
Most - if not all - mainstream Linux distributions per default don’t even set a password on the ROOT account. Thus completely preventing login with the account.
Instead, during the setup, they create a “User” account (which is added to the SUDO group) where the user selects both the “Username” and provides a unique password.
The first time setup script of the Omnia could do something similar. And while you are right to some degree that you could then login with that user and through sudo become root it would be more secure just because of the simple fact that an attacker would not know what username the user has selected. An attacker can no longer rely on a standardized username like root (or admin for that matter - the username should obvious not be either of those).
" … besides, you can’t log in via ssh over the WAN port, …"
You can - just has to be enabled. And it is positive that (contrary to some cheap ass mainstream routers) this is not enabled by default.
Since the Omnia sits as the firewall/gateway device being able to login to it and use it as a bridgehead SSH hop to reach hosts/servers on the LAN behind it may be a use case some users may want/need (although in this case you should most definitely configure it with private/public keys instead)
Again - this all boils down to users wanting to experiment with the CLI to learn something. The first lesson should be how to correctly configure security when using the CLI.
" … and if the end-user has internal threats …"
If the user - as you say - is just the normal home user who “just” uses the basic web interface to mess with the Omnia then most certainly there is a good chance they have internal threats.
Just one example from the “IoT-revolution”, Web Cams.
Many web cams (and other IoT products) you buy today will use UPnP to punch a hole in the firewall and setup a port forward so you can reach the web cam from the internet, the Omnia supports these UPnP redirects. Many of the web cams (and IoT devices) have abysmal security configurations and glaring holes that an attacker can exploit in seconds to get on the inside of a network - now they can launch an internal attack on the Omnia.
Best security practice is that a device that acts as you gateway between the internet and the internal network is secured both from external and internal threads and that both networks are seen as equally insecure.
I’m aware that best security practice also states that you should not install shitty IoT devices on your network … but we all have to start somewhere.