> So what happens if ssh (IIRC correctly in typical configurations it depends on network to start) fails to start at boot?
I do this for my main desktop. If the worse of the worse happen, I've got backup of everything (we all do right?) and I re-install the system.
What I mean is: what do you do when you SSD is dead? You can't even login at failsafe console either.
In 30 years of using Linux I've have hard disk die on me way more than I had my sshd daemon not starting. The ratio is even a divide-by-zero error.
Arguably if my OS had its sshd daemon randomly not starting, it'd be an indication to me that it's time to move to a more stable OS.
> What does this actually buy us over sudo or su?
Much harder to pull local privilege escalation exploits.
That's not certain. sshd is way bigger than sudo, so chances of it having an exploitable bug seem higher.
Linux consoles (the ttys that appear over local display or remote-access KVM, or the ttyS* devices that appear over serial ports and IPMI SoL) do not use sudo or su. Those consoles use a program like `getty`, or a window-manager; all those programs are non-suid programs that are started as root.
Your system should have a root password set, for logins via console.
TFA says that he's prefixing his password hash with '!', making login with a root password impossible (including at the console).
Hence GP's question.
For the platform infra teams, if you just need something like metrics and logs, that's already off box. If you need to trigger some job or workflow, you can use the pipeline.
But when someone does log in and do root stuff, I want to have an audit log.
I actually can't think of a single box I own where someone with a login doesn't also have root for everything.
Obviously, I understand the services doing setuid thing, but in the case of services, you generally have systemd doing setuid to drop permissions instead of the other way around.
For less fatal emergencies, I don't see anything that would tie this instance of sshd to tge network.