Or?

The aim of email encryption is in a large part to prevent government-level parties from reading the emails. It doesn't really make sense to then go back to a system controlled by the very same parties.

OpenPGPs web-of-trust model seems more appropriate.

But both approaches share a significant number of problems, so...

  - Subjects can't be encrypted.
  - Encrypted mailing lists are complicated. Do you reencrypt in the middle?
    What software do you use? The mailing list manager you use right now probably doesn't support it.
  - Enigmail still doesn't support storing e-mails decrypted*. As a consequence, full-text search doesn't work.
  - There's also S/MIME.
  - Theres no software to manage public/private keys enterprise-wide.
  - Legitimate server-side email retention requirements for enterprises
  - Many people are quite alright with "most other people won't be able my email; maybe governments can".
  - Most emails quite simply aren't that important.
  - How do you deal with lost keys?
  - Webmailers
  - Often, as a sender at a company, you can not afford to inconvenience contacts.
  - No easy way to synchronize keyrings.
  - Server side spam filtering not possible
  - Out-of-office auto-forwarding
  - The other side uses gmail.
  - Your mother keeps asking why you aren't on Whatsapp.
  - The "metadata" (who mail whom? when? how long are the emails?) is quite telling.

Sorry for the unreadable list. Thank pg for the shitty markup format.

Also, because Bash is a particularly horrible language. I have a lot of experience writing bash scripts, and I hate bash.

Though direct remote code execution is probably much, much more likely than authentication bypass.

@Partitions: Seperating /home and / prevents normal users from filling up /. (And if you put both on LVM, you can grow them as needed.) Yes, I've only had this on some of the servers I've run.

@Impractical: it's one additional command for something I do quite often[4], and I still don't see the benefit (reminder: I fully agree with never using "PermitRootLogin yes").

[3] Granted, it does provide some context seperation in the sense that if you want to perform an administrative task, you have to explicitly use sudo. But it doesn't increase security, and it offers no advantage over "direct root access + normal user account".

[4] Not just scp, but also things like "less /var/log/messages" or "git clone root@host:/etc".

And again: what does "PermitRootLogin no" gain you over "without-password"? Why restrict it for no additional benefit?

I said "impractical", not "impossible". Of course I can use sudo. But it's more work. I require root access a lot. It adds up quickly.[2]

And I hate typing passwords/passphrases. In fact, many of my passwords I can't remember. I've got an SSH agent for that, which reduces passphrase entry to yes/no (tab-space/space, actually).[1]

Also, I prefer my normal user account not to be a sudoer at all.

Besides, please consider that disallowing root access actually only gets you protection against root password guessing anyway. The "stolen key + passphrase" scenario in a sibling subthread is so absurd I felt the urge to bang my head against my desk. Sudo won't help you there either.

[1] Now please don't suggest "passwordless sudo".

[2] And there is another inelegance: /home is usually on a different partition than /, so your way will involve an additional copy. If /home is even large enough to fit that file.

Getting by /without/ direct SSH root access is often impractical (think about scp), and without-password is a secure way to have it.

Also, the more people know about "without-password", the less people will set PermitRootLogin to "yes".

Of course multicopter flight times, especially with payloads, are problematic.

If the company requires more than what can be done in a 40-hour work week, it should hire more employees.