Not the literal string irrelevant, but a correctly configured Unix host can be quite secure. To the point that 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!
There is more on my page showing how to harden Linux and BSD, but the short version for BSD Unix is:
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 (probably the case on BSD, as shown below)
or /bin/su (probably the case on Linux):
# chgrp wheel /usr/bin/su # chmod 4550 /usr/bin/su # ls -l /usr/bin/su -r-sr-x--- 1 root root 22396 2008-01-11 23:16 /usr/bin/su
The meaning of those bits displayed as -r-sr-x--- is:
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
| setgid
setuid
The file /etc/ttys 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.
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 DSA/RSA cryptographic keys PasswordAuthentication no
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 RSA/DSA private keys for someuser stored in my account's ~/.ssh/id_rsa and ~/.ssh/id_dsa. 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.
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 removeable 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 RSA/DSA keys on this machine. 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:
Fine. It's rootpw because I have to remember it.
Maybe it is, maybe it isn't. It doesn't matter, because the security is done elsewhere.
|
||||||||||||
|
||||||||||||
