Absolute OpenBSD: Unix for the Practical Paranoid

OpenBSD uses many of the standard UNIX password-management programs, such as passwd(8) and vipw(8). OpenBSD also includes a friendly interactive user-adding program, adduser(8). We'll cover that program first and then go on to some of the other tools for more advanced uses.

Adding Users Interactively

If you start adduser(8) at the command line, without specifying any options, it drops you into an interactive shell. The first time you run it, it will ask you a series of questions to determine its default settings. It will save these settings, but don't worry too much; we'll look at how to change your defaults later. You must have root privileges to run adduser(8).

# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells 1 Check /etc/master.passwd 2 Check /etc/group 3 Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input.

Whenever adduser starts, it checks the user configuration files. Vital information is kept in 1 /etc/shells, 2 /etc/master.passwd, and 3 /etc/group. Once adduser is convinced that your user configuration files are not corrupted, it will give you a chance to enter the username you want to create. You'll see in brackets the legal characters for usernames in OpenBSD — specifically, any letter or number, plus the underscore and the dash.

Enter username [a-z0-9_-]: phil

Once you have that, you'll get a chance to enter a real name for the user.

Enter full name []: Philip C.

Next, adduser gives you a chance to choose the users' shell. The list of shells is taken from /etc/shells, with the addition of the "nologin" option. The default shell is shown in brackets.

Enter shell csh ksh nologin sh [csh]: csh

Now you can choose a uid (user id number). By default, OpenBSD starts numbering uids at 1,000 and takes the first available uid. You can change this if you wish, but it's generally not necessary.

Uid [1000]: Login group phil [phil]:

By default, each new user is assigned to a group with the same name as his username. You can assign the user account to a different group if you wish. If you have other system groups defined and you want this user to be part of one of these groups, you can enter it here. If you want this user to be able to use the root password, add them to the wheel group.

Login group is ``phil''. Invite phil into other groups: guest no [no]: wheel

Adduser(8) will prompt you for an initial password and then show you your new user so you can double-check your work. Each field you entered previously is displayed for your approval.

Enter password []: Enter password again []: Name: phil Password: **** Fullname: Philip C. Uid: 1001 Gid: 1001 (phil) Groups: phil HOME: /home/phil Shell: /bin/csh OK? (y/n) [y]:

At this point, you can cancel the whole thing by hitting "n." If the account looks correct, however, you can hit "y" and let adduser create the user.

Added user ``phil'' Copy files from /etc/skel to /home/phil

Finally, adduser will ask you if you want to create a second user. You can do that if you wish, or not.

Add another user? (y/n) [y]: n Goodbye! #

Congratulations! You have added a user to your system. Now that you know how the process works, let's take a look at customizing and configuring adduser(8) to give it the defaults you want.

/etc/adduser.conf

The first time you run adduser(8), it uses your answers to build its configuration file, /etc/adduser.conf. Value assignments in this file control adduser(8)'s behavior. If the variable has multiple legitimate values, those values are surrounded by parentheses. Without further ado, here are the standard things you may set in /etc/adduser.conf. To get a complete list of things that may be set in adduser.conf, you'll need to read the adduser script.

verbose = 1

The verbose flag tells adduser how much detail to give. If you have a verbose of 0, adduser(8) will only present a minimum of information when run. It will assume that you know it is checking the user files in /etc/, for example, and hence not bother to tell you about them. The standard is 1. If you want to debug the adduser program itself, you can set this to 2 for maximum debugging output. I habitually turn this to 0 without a second thought.

encryptionmethod = "blowfish"

OpenBSD supports a variety of encryption schemes for encoding passwords. Blowfish is the OpenBSD standard. If you want to share your password file with other UNIX-like operating systems, though, set this to "old" to get DES hashes.

dotdir = "/etc/skel"

All new user accounts get a set of default shell dotfiles. You can use the ones that OpenBSD provides in /etc/skel, or you can create your own customized for your environment. Any files in this directory will be copied to the user's home directory, so you can also use this to distribute any other files you like. Be sure that regular users cannot put "extras" in a directory you specify!

send_message = "no"

On many operating systems, new users automatically receive a welcome or instructional email message. By default, OpenBSD does not do this. If you put the full path to a file in this variable, however, the contents of that file will be emailed to each new user. If you set this to no, a message will not be sent. OpenBSD does have a default new user message in /etc/adduser.message, but you should feel free to create your own.

The adduser message accepts the variables $username and $fullname; this allows you to customize your welcome message somewhat. (If you're familiar with Perl, you can add your own variables by editing /usr/sbin/adduser.) If you wish, go ahead and create your own message instead of using the brief and generic default. I generally use an /etc/adduser.message.local somewhat like this:

$fullname, Welcome to The Company. Help is available at 800-555-1212, or online at http://helpdesk.companyname.com. Use of this account is governed by our acceptable use policy, available at http://www.companyname.com/aup.html or on this system in /usr/local/share/company/aup. Thank you for your business. We look forward to serving you. The Company Support Staff.

logfile = "/var/log/adduser"

Adduser will record the history of its actions in the file specified here.

home = "/home"

This variable controls the directory where users' home directories are located. This is one of the first things I take care of on any OpenBSD system. If you do not specifically create a /home partition, the default will place users' home directories on the root partition. This is bad, for a variety of reasons. The biggest problem in that your root partition is limited to 8GB in size, which greatly restricts the amount of user data your system can hold.

If you expect to have a lot of user accounts on your system (i.e., for a web server), you almost certainly want a /home partition so you can mount it with the appropriate permissions. If you only have systems administrators accounts on this system, you might want to place user accounts under /usr/home and create a symlink from /home. Both work, but you should know about your choices.

path = ('/bin', '/usr/bin', '/usr/local/bin')

This contains the list of directories that can contain legitimate shells. This covers most standard situations, but if you find that you're installing shells in some unusual location, you'll want to edit this appropriately.

shellpref = ('csh', 'sh', 'ksh', 'nologin')

This is a list of legitimate shells. Adduser will let you choose from any of these when creating a new user.

defaultshell = "csh"

This is the default user shell. It can be any of the shells listed in "shellpref."

defaultgroup = USER

This is the primary group that the user is a member of. Traditional BSD systems assign each user to a group of the same name as the username. For example, our "phil" user is automatically a member of the group "phil," which was created just for him. You might want all users to be part of a separate group, such as "students" or "customers." If that's the case, you can set that on this line. You can add this user to other groups manually, but this will be the primary group.

uid_start = 1000uid_end = 2147483647

These give the range of acceptable user ID numbers, or uids. The default is fine for most cases, but you might want to use different numbers to interoperate with your other UNIX-like systems.

Adding Users Non-Interactively

You might need or want to add users in a single, longer command. This is common if you have scripts or cron jobs that add users at regular intervals, for example, or if you're comfortable with remembering long commands with many options. Adduser's -batch flag enables this. When you use this mode, adduser takes four additional arguments: the username, the group name, the full name, and the password in encrypted format, much like this:

# adduser -batch chris wheel 'Chris B.' loser1

Here we create a user account for Chris, put him in the wheel group, and give him a password that encrypts to the string "loser1".

Passwords and Batch Mode

If you actually follow the previous example, you'll create the account without a known password! Remember, no modern UNIX stores its passwords in readable format; instead, it stores a "hash" of the password. If you take the password and perform some horrible computations on it, you'll create a hash. When you create or change a password, the system creates this hash and stores it in /etc/master.passwd. When you attempt to log in, the login process takes your password, generates a hash, and compares the hash of the offered password with the hash in the password file. If the hashes match, exactly, the login is permitted.

The example above creates an account with a password hash of loser1, not a password of loser1! This isn't even a legitimate hash, and no entered password will match it. Most of us cannot calculate Blowfish hashes from known text in our heads; we either need pre-generated encrypted passwords, or we need to enter unencrypted passwords on the command line and have adduser do the calculation for us, or we must create an account with no password at all.

Creating an account without a password is perhaps the simplest option. The account is disabled until you go back and enter a password, but this may be acceptable for accounts used to run daemons and services. Simply run adduser in batch mode, omitting the password.

# adduser -batch chris wheel 'Chris B.'

If you want to enter an unencrypted password on the command line, you can do this with the -unencrypted option. Be sure you put this option before the -batch option! For example, if I wanted Chris's account to really have a password of "loser1," I could enter this:

# adduser -unencrypted -batch chris wheel 'Chris B.' loser1

The user now actually has a password of loser1. ^[1] You might use this inside a script, or at some time when nobody is around to look over your shoulder.

Generating Pre-hashed Passwords

If you're using this within a script, you probably want to pre-generate hashed passwords. Encrypt(1) does this. By default, encrypt just gives you a blank line. When you enter a word, it returns the Blowfish-hashed password. You can enter any number of words, and each will be hashed separately. Hit CONTROL-C to exit encrypt.

# encrypt loser1 $2a$06$RdxEtB0DNJ6MY67j77m/Bu.JYydNnErTo2cAV0InHg5gkCK1JrbBC ^C #

If you're just doing one password or using this interactively, you probably want to use encrypt's -p option. This gives you a non-echoing prompt for a word to be hashed.

# encrypt -p Enter string: $2a$06$RHWwSGRFSat8byeBcm6W6.H9LKC7Cxi8A2pjqC0hUi8LfHtV6OeQK #

Between these three choices, you should be able to handle passwords in adduser's batch mode in any way you desire.

Other Adduser Batch Mode Options

When running adduser(8) in batch mode, you have several other options to override the default configuration. I will frequently set up administrator accounts in one way and user accounts in another, and use different tools to create each. Frequently, sysadmin accounts are created in adduser's interactive mode — I don't have many systems administrators on any given system. Someone else running a script that I've written creates user accounts on a routine basis. You can get a complete list of adduser options by reading adduser(8). These are simply the options I find most useful.

The -noconfig option tells adduser to not read the default /etc/adduser.conf. Using this in a script is an excellent way to make sure administrator-friendly settings in /etc/adduser.conf do not leak into regular user accounts.

The -dotdir option specifies a nonstandard directory where user dotfiles are stored. All files in this directory will be copied to the user's home directory.

-home tells adduser which directory to create a new users' home directory in. This is not the actual home directory, but rather the directory where the home directory will be placed. For example, if all of your web server customers have home directories on the /www partition, you might use -home /www on the batch adduser command line.

Account Limitations

A user account is subject to the following restrictions.

• Usernames can contain only lowercase letters, digits, dashes, or underscores. ^[2]

• The full name cannot contain a colon (:).

• The user's shell must be listed in /etc/shells.

^[1]Mind you, this is an absolutely hideous password, for an extraordinarily wide variety of reasons. But if you're interested at all in security, you know that already.

^[2]Technically, you could create a username that contained any character you liked or even multiple identical usernames — but then you run into all sorts of potential problems. Stick with the defaults unless you know exactly what you're doing and are prepared to deal with the consequences.