Linux / UNIX keyboard.

The root password is ... irrelevant

What is the root password on this server?

It's not the literal string irrelevant, the point is that passwords and their security problems can be made irrelevant. A correctly configured Unix 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 immediate advantage for getting in as root. I know the root password for this server, but I still 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!

There is more on my page showing how to harden Linux and BSD, but the short version for BSD Unix is:

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

This is already the default on BSD!

But before you go any further, to prevent locking yourself out of your own system, make sure that your personal unprivileged account is a member of group wheel!

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 use the command:
# which su
to see if it is /usr/bin/su or possibly /bin/su. Then change the permissions so it 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  16568 Aug 16  2015 /usr/bin/su 

The meaning of those bits displayed as -r-sr-x--- is 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 here for 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)

[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 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
# > /etc/securetty 

[3] Set up SSH service cautiously

Put the following in /etc/ssh/sshd_config and restart the SSH daemon:

# Only run the SSH2 protocol, refuse SSH1
Protocol 2
# Do not allow root to login over SSH
PermitRootLogin no
# Only allow one user to login over SSH...
AllowUsers someuser
# ...and require that user to authenticate
#    using ECC or RSA cryptographic keys
PasswordAuthentication no

So how can I get in?

First, I need to know the username someuser. And no, it is not literally someuser!

Second, I have to start from a system that has the ECC/RSA private keys for someuser stored in my account's ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, and ~/.ssh/id_ed25519, ~/.ssh/id_rsa. That would appear to require me to be either at my home or using my laptop. However, see this page for a description of how to put a Linux system and an emulator on a USB thumbdrive. That way, all I need is my thumbdrive and the use of some Internet-connected system.

Third, those keys are not stored as cleartext data, but they are encrypted with 3DES using a passphrase as the key. I must run the command ssh-add and type that passphrase. So, the loss or theft of my laptop or USB thumbdrive is limited to denial of service, not authentication spoofing.

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 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 keys for root Uh, root doesn't have personal ECC/RSA keys on this machine. No /root/.ssh/ at all. Sorry, but I hadn't mentioned that above.

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 3DES encryption of the key files. I would prefer that OpenSSH used something stronger than 3DES (say, AES or Blowfish), but 3DES is going to be fairly strong. Brute-force searching for my pass phrase is going to be much easier than finding the 3DES key itself.

2: Intercept an SSH user authentication session and break the ECC or RSA encryption used for that session. My RSA key is 2048 bits. ECDSA is 521 bits, and ED25519 is 256 bits. According to a NIST and NSA report on the key lengths in bits for approximately equal resistance to brute-force attacks, 1024-bit DSA is about like 80-bit symmetric (which turns out to be the known limit to 3DES), 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 3DES 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:
9620 = 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, so:
2720 = 42,391,158,275,216,203,514,294,433,201
Limiting the search space to sequences of English words 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.

My page on hardening Linux and BSD
My general computer / network security page