## Recognize basic recommended access methods ##

[Author](authors.html): [[KevinDKinsey]]

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

----

### Concept ###

Be familiar with standard system administration practices used to minimize the risks associated with accessing a system.
These include:

* using **`ssh`** instead of **`telnet`**
* denying root logins
* (possibly) using the third-party **`sudo`** utility instead of **`su`**, and 
* minimizing the use of the wheel group.

### Introduction ###

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.

### Use `ssh` instead of Telnet or `rsh/rlogin` ###

`Telnet(1)` was an early implementation of a "remote control" application.  Another early program set for remote
administration was `rsh(1)` and `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 `telnet` or `rsh` and `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 `telnet` or `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 `rsh`, `rlogin` or `telnet`, OK?  Use `ssh` instead!

`ssh` consists of two programs developed by the OpenBSD team, `ssh(1)` and `sshd(8)`.  `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 `rsh/rlogin` and 
`telnet`, and also provide you with more security --- using `ssh` ensures your sessions are protected by strong encryption.

More about `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 `chown(8)`, `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 `sudo` ###

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 `mount` and `umount` media but not `newfs` them, etc.)

For more information about `sudo`, install it and read the manpage, or visit <http://www.sudo.ws/>.

### Examples ###

####Connecting to a remote machine:####

""$ **telnet myserver.example.com**

    Trying 6.7.8.9...
    telnet: connect to address 6.7.8.9: Connection refused
    Trying 6.7.8.9...
    telnet: connect to address 6.7.8.9: Connection refused
    telnet: Unable to connect to remote host

Good!  Telnetd isn't enabled on your remote machine!

""$ **ssh me@myserver.example.com**

You may see a banner message at this point.  If you are using password-based authentication, you will be prompted:

    Password:

Enter your passphrase and you will see information from various files and programs; among them, last(1), uname(1), and `/etc/motd`:

    Last login: Wed Jan 10 11:29:26 2007 from 9.8.7.6

    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 `user@host` syntax #####

In the example above we used `user@hostname` with `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 hostname`, `ssh` will attempt a login using the name given by id(1).

####Using `su` and `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**:

""$ **su**
    Password:

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 `$EDITOR` on `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**

Depending on `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`:

""$ **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"**

We have `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.

### Practice Exercises ###

1.  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.
2.  Use `ssh` to connect to a remote machine.
3.  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*

4.  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.

### More information ###

`ttys`(5), `sshd_config`(5), `ftpusers`(5); the (possibly third-party, depending on your BSD flavor) utility
`sudo` which includes `visudo`(8), `suedit` and `sudoers`(5). 
