What is the
on this server?
root password is irrelevant!
It's not the literal string
The point is that passwords and their security problems
can be made irrelevant.
A correctly configured Linux 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
I know the
root password for this server,
but I cannot login as
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:
Limit execution of the
sucommand to members of group
rootlogin, either on directly connected terminals or remotely over SSH.
- Disable password authentication over SSH, require cryptographic authentication.
 Limit execution of
to members of group
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
The problem is that
is a very useful command.
d are adjacent
on the keyboard, and so it's a common error to type
su when you meant to type
If all users can execute
su, these common
typing errors create log entries that you must somehow
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
It always seems to me that they're looking for a technical
fix to the problem caused by their hiring untrustworthy
And, that they're fixated on punishment.
OK, let's restrict the use of the
Danger You can lock yourself out of your system if you aren't careful!
Before continuing, make sure that your account is a
member of group
And, ideally, make sure that you're already
in another window, so you have a way to fix any errors!
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
My example shows it in
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
# chgrp wheel /usr/bin/su # chmod 4550 /usr/bin/su # ls -l /usr/bin/su -r-sr-x--- 1 root root 17792 Sep 15 14:05 /usr/bin/su
The meaning of those bits
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
Distributions derived from Debian, such as the very popular
su and allow all members of groups
sudo to execute any
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
transitioning into a fully interactive command-line session
with no logging on individual commands.
on the console
/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
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
root password when going to
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
is similar to the word "security", so it's very easy to
mistakenly create an empty file named
That does the opposite of what you want,
while causing no error messages!
The logic is:
If the file
/etc/securettyexists, the concept of a "secure TTY" matters. That's a place you would allow
rootlogin sessions. So, examine the file:
If the file contains a list of devices,
those are the places where
rootcan log in. Your system will come with a list of all possible such devices, both physical TTYs on serial ports (
ttyS1, and so on) and virtual TTYs (terminal emulators,
tty1, and so on, plus
vc/2, and so on). That original file effectively means "everywhere", so
rootlogin is allowed.
If that file exists but is empty,
it means that the concept of "secure TTY"
exists and there are no such devices.
rootlogin is not allowed.
- If the file contains a list of devices, those are the places where
If the file does not exist, then the
concept of "secure TTY" does not matter.
rootlogin is allowed everywhere.
You will also need to require the
module in the PAM file for
and also for your display manager if it doesn't already
/etc/securetty on its own.
I have found that the easiest way to figure this out,
and the only trustworthy way,
is to experiment.
securetty file empty and see if you
can log in as
root on the graphical console.
If you can still authenticate as
experiment to find which PAM file the display manager uses.
 Set up SSH service cautiously
I have a series of pages describing
how to set up SSH.
All we need to disable
is to put the following in
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
And no, it is not literally
Second, I have to start from a system
that has the ECC and RSA private keys for
someuser stored in my account's
That would appear to require me to be either
at my home or using my laptop.
However, I can
put a Linux system and a
hypervisor 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
AES-128 using a passphrase as the key
ssh-keygen manual page
I must run the command
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
If you got to the physical console, then yes, you could
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
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
See the above for why this would be useless even if I
had not removed the
in the file
But I did, so this would be doubly useless.
The cryptographic SSH keys for
There's no such thing.
root account doesn't have
personal ECC/RSA keys on this machine.
/root/.ssh/ at all.
The cryptographic keys for
Well, yes, this would let you in.
But to do that, you are going to have to break some
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 2048 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 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!
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.