The root password is ... irrelevant

What is the root password on this server?

The root password is irrelevant!

It's not the literal string irrelevant. The point is that passwords and their security problems can be made irrelevant. A correctly configured Linux or BSD or other Unix-family host can be quite secure, and here is how to set it up.

If you configure a Unix system correctly, knowing the root password gives you no advantage for getting in as root. I know the root password for this server, but I cannot login as root on my own server!

Don't worry about making the password "strong enough".

Don't bother changing the password "often enough".

Make it so passwords can't be used.

Passwords are of very limited use for hardening security. Simply disable password authentication for sensitive accounts and avoid this problem!

Keep reading for a step-by-step procedure of how to improve your server's security. The short preview is:

1. Limit execution of the su command to members of group wheel.
2. Prevent direct root login, either on directly connected terminals or remotely over SSH.
3. Disable password authentication over SSH, require cryptographic authentication.

[1] Limit execution of su to members of group wheel

This is already the default on BSD! It's an easy change on Linux, where it can eliminate a lot of unneeded hassles in settings with strict security policies.

Many organizations cause themselves trouble by requiring themselves to track down the details of every failed su run. The problem is that du is a very useful command. However, s and d are adjacent on the keyboard, and so it's a common error to type su when you meant to type du.

If all users can execute su, these common typing errors create log entries that you must somehow account for. But if most users did not have permission to run the su command, they would get a simple "Command not found" error and nothing would be logged.

Some people object to this fix, saying that they want to track down and investigate the people who run su. It always seems to me that they're looking for a technical fix to the problem caused by their hiring untrustworthy people. And, that they're fixated on punishment.

OK, let's restrict the use of the su command.

Once you are absolutely certain you can use an account that is a member of group wheel, you can do something like the following. First, find out whether the command is in /usr/bin/su or possibly /bin/su. My example shows it in /usr/bin, with the less secure default permissions found on Linux.

$ which su
/usr/bin/su
$ ls -l $(which su)
-rwsr-xr-x  1 root  root   17792 Sep 15 14:05 /usr/bin/su 

Now, change the permissions so the command retains its SETUID nature but can only be executed by the owner (root) and members of the group wheel:

# chgrp wheel /usr/bin/su
# chmod 4550 /usr/bin/su
# ls -l /usr/bin/su
-r-sr-x---  1 root  wheel  17792 Sep 15 14:05 /usr/bin/su 

The meaning of those bits displayed as -r-sr-x--- corresponds to octal mode 4550, where:

 Octal:      4       5       5       0
Binary:    1 0 0   1 0 1   1 0 1   0 0 0
Meaning:   ^ ^ ^   user    group   other
           | | |   r w x   r w x   r w x
           | | |
           | | sticky  (not generally used on *nix files any more,
           | |          see the historical details if you care)
           | setgid    (if 1, process has effective GID of file's group)
           setuid      (if 1, process has effective UID of file's owner)

You could do the same for the sudo command.

Warning Distributions derived from Debian, such as the very popular Mint Linux, disable su and allow all members of groups admin and sudo to execute any command through sudo. This provides just the illusion of increased security and improved logging of privileged commands. It quickly occurs to most such users than they can run the bash shell with sudo, transitioning into a fully interactive command-line session with no logging on individual commands.

[2] Prevent root login on the console

The file /etc/ttys on BSD will contain several lines resembling these:

console "/usr/libexec/getty Pc"    vt220   off secure
ttyC0   "/usr/libexec/getty Pc"    vt220   on  secure
ttyC1   "/usr/libexec/getty Pc"    vt220   on  secure
[....]

Edit that file and delete every instance of the string secure, otherwise leaving those lines alone, so the file begins:

console "/usr/libexec/getty Pc"    vt220   off
ttyC0   "/usr/libexec/getty Pc"    vt220   on
ttyC1   "/usr/libexec/getty Pc"    vt220   on
[....]

If you mark the console as "insecure", the system will demand the root password when going to single-user mode. Leave the console marked as "secure" if you sometimes access the system at the physical console. Your server room should be physically secured to start with.

If you are instead doing this on Linux or an SVR4 Unix, make the file /etc/securetty be an empty file.

# mv /etc/securetty /etc/securetty-BACKUP
# touch /etc/securetty 

Be careful — the file name securetty is similar to the word "security", so it's very easy to mistakenly create an empty file named /etc/security instead. That does the opposite of what you want, while causing no error messages! The logic is:

• If the file /etc/securetty exists, the concept of a "secure TTY" matters. That's a place you would allow root login sessions. So, examine the file:
  • If the file contains a list of devices, those are the places where root can log in. Your system will come with a list of all possible such devices, both physical TTYs on serial ports (ttyS0, ttyS1, and so on) and virtual TTYs (terminal emulators, tty0, tty1, and so on, plus vc/1, vc/2, and so on). That original file effectively means "everywhere", so root login is allowed.
  • If that file exists but is empty, it means that the concept of "secure TTY" exists and there are no such devices. Therefore root login is not allowed.
• If the file does not exist, then the concept of "secure TTY" does not matter. Therefore root login is allowed everywhere.

You will also need to require the pam_securetty.so module in the PAM file for login, and also for your display manager if it doesn't already read /etc/securetty on its own. I have found that the easiest way to figure this out, and the only trustworthy way, is to experiment. Make the securetty file empty and see if you can log in as root on the graphical console. If you can still authenticate as root, experiment to find which PAM file the display manager uses.

Changes in RHEL 8: Red Hat no longer includes the /etc/securetty file, but it has the pam_securetty.so PAM module. You can first insert a new first auth line in the login PAM file (highlighted below), and create an empty securetty.

# grep -w auth /etc/pam.d/login
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       substack     system-auth
auth       include      postlogin
# echo '' > /etc/securetty

Then, if you use a graphical console, research and experiment to determine which PAM files it uses. On Red Hat, it's gdm-password unless you have set up something unusual.

[3] Set up SSH service cautiously

I have a series of pages describing how to set up SSH. All we need to disable root access is to put a few directives in /etc/ssh/sshd_config and restart the SSH daemon.

[... other lines deleted ...]

# OpenSSH dropped support for the SSH-1 protocol in 2016,
# see the OpenSSH Release Notes at https://www.openssh.com/txt/release-7.4.
# Do not include the now-unneeded "Protocol 2" directive
# because that would prevent the server from starting.

# Several important settings may now have safer defaults.
# However, that depends on the server's version of OpenSSH.
# Verify these with your manual page.

# Do not allow password authentication, require the user to
# authenticate with ECC or RSA cryptographic key pairs.
#
# PasswordAuthentication defaults to "no" on FreeBSD 13 with OpenSSH 9.3.
# However, it defaults to "yes" through OpenSSH 8.9, and so this setting
# is needed on:
#  -- Oracle Enterprise Linux 9.2 with OpenSSH 8.7
#  -- Oracle Enterprise Linux 8.8 with OpenSSH 8.0
#  -- Red Hat Enterprise Linux 8.8 with OpenSSH 8.0
#  -- Mint Linux with OpenSSH 8.9
PasswordAuthentication no

# Do not allow root to login over SSH.
# The default is already "no" on FreeBSD 13 with OpenSSH 9.3.
# However, it defaults to "prohibit-password" through OpenSSH 8.9,
# and so this setting is needed on:
#  -- Oracle Enterprise Linux 9.2 with OpenSSH 8.7
#  -- Oracle Enterprise Linux 8.8 with OpenSSH 8.0
#  -- Red Hat Enterprise Linux 8.8 with OpenSSH 8.0
#  -- Mint Linux 21 with OpenSSH 8.9
PermitRootLogin no

# Optionally, only allow these two users to login over SSH.
# Uncomment the following line to turn this on.
# AllowUsers someuser otheruser

[... other lines deleted ...]

But what if I had ....

The UNIX login password for someuser — If you got to the physical console, then yes, you could get in. But if you could get to the physical console, you could boot from removable media! So you would just have a less effective method of doing what you could do anyway with physical access.

Because of the line PasswordAuthentication no in /etc/ssh/sshd_config, you cannot authenticate to SSH with a login and password. So the UNIX login password for someuser is useless from a distance.

The UNIX login password for root — See the above for why this would be useless even if I had not removed the secure field for /dev/console in the file /etc/ttys. But I did, so this would be doubly useless.

The cryptographic SSH keys for root — There's no such thing. The root account doesn't have personal ECC/RSA keys on this machine. There's no /root/.ssh/ at all.

The cryptographic keys for someuser — Well, yes, this would let you in. But to do that, you are going to have to break some serious cryptography. You will have to do one of the following:

1: Steal my laptop and break the AES-128 encryption of the key files. Searching for my pass phrase is going to be much easier than a brute-force search for the 128-bit AES key itself.

2: Intercept an SSH user authentication session and break the ECC or RSA encryption used for that session. My RSA key is 4098 bits. ECDSA is 521 bits, and ED25519 is 256 bits. 1024-bit DSA is no longer used — its security at best was about like 80-bit symmetric (which turns out to be the known limit to 3DES), and it's far worse with typical random number generators. According to a NIST and NSA report on the key lengths in bits for approximately equal resistance to brute-force attacks, 2048-bit RSA is about like 112-bit symmetric (the design strength of 3DES), 521-bit ECDSA is about like 256-bit symmetric, and 256-bit ED25519 is about like 128-bit symmetric.

3: Steal my laptop and do a brute-force search for my pass phrase used to generate the AES-128 key. Since I must type the pass phrase with no visual feedback as to what I'm typing, this is going to be the most practical way to get those keys. It's over 20 characters long, there are 96 printable ASCII characters on a US keyboard, and so a lower limit on the search space is:
96²⁰ = 4,420,024,338,794,077,316,988,270,789,431,736,139,776
If we stick just to alphabetic-only sequences at least 20 characters long, that's still an astronomically large search space. Twenty-six letters plus blank space but no digits or punctuation, so:
27²⁰ = 42,391,158,275,216,203,514,294,433,201
Limiting the search space to sequences of English words, with the sequence at least 20 characters long, that's still an awfully large space.

But, you said you would tell me!

Fine. It's rootpw because I have to remember it.

Look, maybe it is, maybe it isn't. It doesn't matter, because the security is done elsewhere.