The design of telnet and ssh where you have a daemon running as root is bad security that as shown here is a liability, a ticking time bomb ready to give attackers root.
I think we all collectively decided that that was a bad idea at some point — probably because /bin/login was never designed under the assumption that it would have to deal with arbitrary binary network traffic being thrown at it (it really only expects keyboard input.) So we switched to doing auth directly in our network daemons, since at least then “people who are aware the code is network-facing” would be maintaining it.
2. give up root because you don't need it any further.
3. Only accept non-root logins
4. when a user creates a session, if they need root within the session they can obtain it via sudo or su.
You presumably want them to run as any (non root) user. The capability you need for that, to impersonate arbitrary (non-root) users on the system, is pretty damn close to being root.
It doesn't matter what user it is running as.
If this was so easy to deal with, someone would have done it. Instead, we get endless HN comments about people that act like they can do better but never submit a PR.
>If this was so easy to deal with, someone would have done it.
Sadly this is not the case. There is a lot of inertia towards solutions like ssh or sudo. It may be easy to delete them, but actually getting such a changed accepted is no trivial task.
Yes, but potentially any login. See the problem? If you compromise the gatekeeper, you are now the keymaster. Or whatever :)
I suppose it could be via a proper PAM module, which is widely supported.
Too bad the first PAM RFC was published about the same time the first be version of ssh was released.
One can disable root login via SSH in /etc/ssh/sshd_config. sshd also drops root priviledges once it's running IIRC.
I use use sudo or doas as a regular user once logged in.
Sshing as a regular user and then sudo to root works 95% of the time…