This is the BSDA Study Guide Book written via a
This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Recognize_basic_recommended_access_methods.html.
Recognize basic recommended access methods
Be familiar with standard system administration practices used to minimize the risks associated with accessing a system.
ssh instead of
- denying root logins
- (possibly) using the third-party
sudo utility instead of
- minimizing the use of the wheel group.
Many BSD machines are used as "servers" in locations away from the system administrator. Since
the earliest days of networking, methods have been developed to access one machine from a terminal
or another machine. Access to remote machines, particularly those accessible from the public Internet,
must be secured from access by unauthorized personnel. In addition, good security practice demands that
we limit the number of people who know (or need to know) root's password at all.
ssh instead of Telnet or
Telnet(1) was an early implementation of a "remote control" application. Another early program set for remote
rlogin(1). While these are still valid for limited uses today, they should never be used to administrate a machine over a network, because all data in
rlogin is transmitted without encryption, or in "plain text". Anyone with the ability to run a "packet sniffing" program could read your password and all other transactions between you and your system if you use
rsh/rlogin. Except in limited circumstances, such as in a locked-down facility with hungry guard dogs and a single armored cable which no one else can access between you and the server, which is in plain sight and surrounded by an electric fence, don't use
telnet, OK? Use
ssh consists of two programs developed by the OpenBSD team,
ssh is a client program
which provides terminal access (and other features) to another machine.
sshd is a server daemon which
runs on the "other machine". Together, these two programs provide all the features (and more) of
telnet, and also provide you with more security --- using
ssh ensures your sessions are protected by strong encryption.
ssh appears in the following paragraphs and the next three sections.
Deny Root Logins
Since the "root" account can do anything at all to a system, good security practice requires that root
logins be restricted to the physical console of the machine itself, and, usually, only in dire circumstances.
Both local and remote (
SSH!) logins should be as a "normal" user, and normal users who need
to run programs that require root's authority should use an alternate method to "get root".
Reasons for this are many, vary in importance to various individuals, and are frequently discussed in newsgroups, e-mail lists, internet forums, and other materials. Briefly, here are some things to think about:
The "onion" principle of security: if someone compromises remote access, is it better that they get
limited capabilities, or root privileges? What if they have access to the machine's console and have seen someone login a few times? If so, what if their memory is photographic?
The "oh my!" principle of sanity: someday, sometime, someone will have a bad day. If someone is logged
in as root when that happens, the possibility for much more damage exists. The classic example of this argument is in the use of
rm(1), but plenty of havoc can be wreaked with
chmod(1), and other programs as well. File permissions are one protection from these types of errors, but permissions don't do any good if you're logged in as root when a mistake occurs.
The "oh no!" principle of spitefulness: in real life and real work, people get fired, canned, terminated, and, sometimes, angry about it. If your superior fires a team member on a day when you're not there to turn off their access to the system, and they know the root password, there is a chance, no matter how "nice" that person may seem, of them manifesting a streak of vindictiveness prior to cleaning out his/her desk or cubicle, with potentially damaging results.
For more on this subject, keep reading. To set
sshd to deny root logins, see the next section Configure an SSH server according to a set of requirements.
su, the "wheel" group, and
Since we want all logins to be by "normal" users, how will we accomplish tasks like software installation,
modifying system-wide configuration files, restarting daemons, or rebooting the system?
Traditionally, anyone who has a need to do this sort of chore is a member of the "wheel" group. Only members
of this group are allowed to use
su to gain root privileges. In order to "get root" with
su, you must
enter the root password and "become" root.
More recently, many system administrators use
sudo to allow root privileges.
Sudo was developed at SUNY/Buffalo in 1980 and is currently maintained by OpenBSD; it is available in their default install, or via the ports/packages system on other BSD flavors.
sudo is highly configurable, contains extra notification and security mechanisms, and can even be configured to allow groups of users access to a limited set of commands (for example, to allow the webmaster to restart
httpd, but not restart the system, or to allow normal users to
umount media but not
newfs them, etc.)
For more information about
sudo, install it and read the manpage, or visit http://www.sudo.ws/.
Connecting to a remote machine:
$ telnet myserver.example.com
telnet: connect to address 126.96.36.199: Connection refused
telnet: connect to address 188.8.131.52: Connection refused
telnet: Unable to connect to remote host
Good! Telnetd isn't enabled on your remote machine!
$ ssh email@example.com
You may see a banner message at this point. If you are using password-based authentication, you will be prompted:
Enter your passphrase and you will see information from various files and programs; among them, last(1), uname(1), and
Last login: Wed Jan 10 11:29:26 2007 from 184.108.40.206
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 6.0-RELEASE-p13 (GENERIC) #3: Thu Sep 28 20:02:55 CDT 2006
Welcome to FreeBSD!
If you use key-based authentication, no password is required. Your shell resource scripts will be called, your environment set up, and you should receive a shell prompt:
You are now "logged in".
a word about
In the example above we used
ssh to specify the remote account and remote server to connect to. Other methods to specify the username include editing the local
~/.ssh/config file or using the "-l" flag when calling
ssh. If you simply
ssh will attempt a login using the name given by id(1).
sudo to gain root privileges:
Let's do a chore that requires root's power to accomplish. Suppose we want to enable natd(8), the "Network Address Translation Daemon", at the next bootup:
$ echo 'natd_enable="YES"' >> /etc/rc.conf
/etc/rc.conf: Permission denied.
As a "normal" user, you can't append (or edit)
/etc/rc.conf; it's owned by root and "chmodded" to 744 for security reasons (and should be!) So, use su:
If you are in the wheel group, you are prompted for the root password (if you are not in the wheel group, you simply get
Su: sorry). If you enter root's password correctly, you get a new shell with root's prompt and environment. Now try the command:
# echo 'natd_enable="YES"' >> /etc/rc.conf
It succeeds silently, and the directive is added to the rc.conf file.
If sudo(8) is on your system, you must edit the
sudoers file as root before attempting to use
sudo. Use the visudo(8) program to invoke
sudoers and set permissions appropriately. After this, allowed users should be able to accomplish "root level" tasks with
sudo like this:
$ sudo shutdown -r now
sudo's configuration, the command may succeed silently, or the user may be prompted for their own password (instead of the root password). Coinfiguring
sudo to work without a password prompt is very convenient, but the password prompt is also a great behavior for at least two reasons: 1] it means that the administrators don't have to actually know the root password to do "important" tasks, thereby protecting password integrity, and 2] the user is reminded that he/she is about to do something using root privileges, and will hopefully think carefully about the command before continuing.
Using the first example above, something strange seems to happen when prefaced by
$ sudo echo 'natd_enable="YES"' >> /etc/rc.conf
/etc/rc.conf: Permission denied.
This is because
sudo executes the echo command, but stops at the redirect, so the "normal user" is attempting to redirect to the protected file. It's a tad tricky (watch the quotes!), but here's a way around this problem:
$ sudo sh -c echo "'natd_enable="YES"' >> /etc/rc.conf"
sudo call a single command, "
sh -c", as root, and this
/bin/sh process takes care of both the echo call and the redirection using root's UID. You could have similar problems if you try something like
sudo foo && bar - you would need to call
sudo for both commands, or do some quoting magic.
- Attempt to use
telnet to a remote machine. If you get a password prompt, disconnect immediately and call the machine's administrator as soon as possible.
ssh to connect to a remote machine.
If you are the system administrator/owner or a member of the wheel group on a system, login as a normal user and use
su to get root. Edit
/etc/rc.conf and add the line:
# This line added by me on date
If you are the system administrator/owner or a member of the wheel group, install
sudo and configure it to allow you to use it. Call
sudo $EDITOR /etc/rc.conf at your prompt, then remove the line you added in exercise 3.
ftpusers(5); the (possibly third-party, depending on your BSD flavor) utility
sudo which includes