IMHO "sudo" (or "doas") should be used from a different user, by switching to a different VT. Or at least only allowing certain commands for you day to day user.
And I agree that the typical sudoers config that allows opening terminals as root isn't a good idea.
What I prefer lately is using a yubikey neo to ssh access a root shell. You can configure sudo and authorized_keys to allow directly opening a root shell and you never enter any passwords anywhere except the pin to unlock the yubikey's openpgp applet. The yubikey will lock the key after six unsuccessful pin attemps and you can just yank the key out when it's not being used.
Now all I need is some sort of phone app that reaches out to me on a side-channel to pops up asking me to authorize each login (something like libpam-askmeonmyphone)--(I really like the way the Microsoft Account 2FA phone app works in this regard). If I could change one thing about the yubikey neo, it's that I'd require it to make me physically interact with it to decrypt anything (beyond entering the PIN).
That said, I like your use of yubikeys, even better than the phone that's the sort of stuff that should be triggered using a smartwatch.
The confusion with respect to these guidelines is because some BSD-inspired GNU/linux distributions confugure their sudo to use a "wheel" group.
> once your user account is compromised the attacker is root as well
... but only if they also know the root password.
Anyway, the long and short of it is that on GNU/Linux, wheel is only relevant on distributions that use wheel in their default sudo config.
[0] https://unix.stackexchange.com/questions/4460/why-is-debian-...
But my point was that, regardless of whether you use sudo or su, on GNU/Linux or on *BSD, if the account used to elevate priviledges is compromised, the next you elevate you priviledges you should expect the attacker to follow you.
This is what I meant by "the attacker is root as well": it's just a matter of waiting for the next time you use su or sudo.
(I disable credential caching with "Defaults timestamp_timeout=0" in /etc/sudoers.)
Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.
That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every command reminds them they're acting as root.
If you advocate for only using sudo as a different way to authenticate for a root shell that's cool and all (I often use it like that too), but you're going to run into a disagreement around the nature of sudo.
And I'm skeptical that having users type sudo a bunch of time when they add a PPA and install a program somehow results in greater awareness, but this is purely an opinion of mine.
The other big reason for using sudo is the ability to change policy wrt which users can be root without changing root password everytime, and that clearly is true.
I do not think that is accurate. As I remember it, sudo gained popularity because it provided better control over access to the "root password" for teams of administrative staff. sudo was lightyears easier and provided much more fine-grained control than figuring out how to design POXIX groups.
1) A mechanism to provide better control over access to root privileges where administrative access must be shared between multiple users.
2) An auditing mechanism to record both operations completed as the root user, as well as failed attempts to perform operations as root (usually authentication failures).
3) A way to remind the user that commands are running as root, as well as a way to avoid accidentally running commands as root, since you're never (without "sudo -i" or "sudo -s" or similar) at an actual root shell.
If you're using "sudo -i"/"sudo -s" all the time, you don't lose anything for #1, and losing #3 is mostly just an inconvenience (it's an extra layer of protection, but it's not even really foolproof even with sudo). Losing #2 (auditing) can be a big deal, though, because, if everything's happening at a root shell (rather than via the sudo command), you lose the audit log that traces what's being done at root. Gaps like that in audit logs should be an indicator that something bad might've happened, but you can't make that assumption if you're routinely doing it yourself, too.