The package shadow-passwd is not listed in this documentation, and I think this may be a good advice to write some lines about it.
If the created user is "just" to avoid login as root thru ssh, no issue an easy workaround is to sudo -i -u root prior running passwd <username> to define new passwd for the related user.
This could be an complementary add-on at the bottom of the page in Manual setup (for me same spirit that not using shadow-useradd shadow-usermod shadow-groupadd)
If user created and added to sudo are not allowed to be root, then regular user can't change its own password as :
busybox is providing the passwd utility/function
it is not possible to change its own password for a regular user as /etc/passwd and /etc/shadow are not RW for regular user, only to root.
Performing chmod u+s /bin/passwd may look as a "simple/quick" fix for people not fully familiar with Linux and busybox. This may looks like "just" fixing a missing suid bit like on other regular Linux distro. Unfortunately, this may lead to a major security failure as it will in fact suid busybox itself and not the separate /etc/passwd binary. Ie: due to this "bad fix" any user login to the system will become root automatically.
I guess some people may argue that "playing with sudo is not a basic install", but I don't feel like an expert myself and OpenWRT is not "packaged/designed" (on purpose) as any other regular linux distro and that need some adaptation/advice/tips.
I did the mistake myself to chmod u+s /bin/passwd but fortunately some pop-up in my brain to say "look not good" while doing it and... a simple new login with test user make it then bright clear in my mind...
Fastest/simple solution is not always as good as expected...
As OpenWRT is, from my point of view, a "general public" solution, I guess some "reminder/note" about shadow-passwd may be welcome in the wiki page to increase awareness about potential harmfull side effect/limitation to not use shadow-passwd package for regular user password change.
I let "documentation team" manage to take in account (or not) my 2cents related to sudo.
Thank you Nicholas, that's a helpful set of changes to the howto: "This how-to helps improve security with sudo when using command-line interface." - looking at your contribution and the page itself I'd say you're right and relevant.
The real question is whether there's any circumstance when OpenWRT would want to reduce an authenticated CLI to less than root privilege, or to allow user privilege to ssh into the system. The developers for the last decade have clearly thought root permission was the way to use the system, that authenticating to any user but root was a complicating step with no practical benefit. If a user has sudo rights then they have automatic access to root, and without access to root no sensible work could be done in that very specialized system environment.
I acknowledge the how-to exists and that it, with your adjustments, is probably technically correct. I don't see that performing the how-to brings any benefit to any user.
The real question is whether there's any circumstance when OpenWRT would want to reduce an authenticated CLI to less than root privilege, or to allow user privilege to ssh into the system. The developers for the last decade have clearly thought root permission was the way to use the system, that authenticating to any user but root was a complicating step with no practical benefit.
Since many years I'm maintaining OpenWRT box as router in 3 different physical locations.
For some remote maintenance purpose (to the OpenWRT itself or for other part of the remote network) I keep the opportunity to ssh to the public IP of the OpenWRT router.
In order to avoid a "brute-force" attack to success on the root account (well-known account), I disable login as root in ssh (uci set dropbear.main.RootLogin='off').
This is why I was deploying sudo on my fresh 24.10.2, just to login with username that is not root nor admin nor any other well-known account
I'm not maintaining "high business value solution", just 3 simple home network so I didn't put in place VPN (but this is in my todo... one day... as something to "ban" IP).
Yes, okay, it's a good reason because nearly all brute-force attempts are to root at port 22. I always switch the ssh port to one with five digits, I've never seen anyone knock on it, and I also block root for any ssh activity, but not on OpenWRT. And I'm not criticizing your choice, it's arguable. But underneath all that is what "brute force attack" implies - the only passwords they can guess are passwords you or I wouldn't dream of using. Successful brute force attacks have idiot passwords like Rover*1 and we don't do that. This is a useful thread, it discusses alternative approaches.
pop-up in my brain to say "look not good" while doing it and... a simple new login with test user make it then bright clear in my mind...