The first time adduser runs, it asks a series of questions to determine its default settings. It saves these default settings, but you can change the defaults later.

# adduser
Couldn't find /etc/adduser.conf: creating a new adduser configuration file
Reading /etc/shells
Enter your default shell: csh ksh nologin sh tcsh [ksh]: 1
Your default shell is: ksh -> /bin/ksh
Default login class: authpf bgpd daemon default staff
[default]: 2
Enter your default HOME partition: [/home]: 3
Copy dotfiles from: /etc/skel no [/etc/skel]: 4
Send welcome message?: /path/file default no [no]: 5
Do not send message(s)
Prompt for passwords by default (y/n) [y]: 6
Default encryption method for passwords: auto blowfish des md5 old
[auto]: 7

adduser first asks for your preferred default shell. It reads /etc/shells to see all the shells installed on your system. Though I’ve long used tcsh, I usually start new users with the OpenBSD standard of ksh 1. That way, they have a shell that more closely resembles what is used by the rest of the world, and they quickly learn that I cannot answer questions about their shell.

Next, adduser asks for your default login class. I’ll cover login classes later in this chapter. For now, assign new users to the default login class at 2.

If you have a default OpenBSD installation, your user home directories are on the /home partition. If not, specify the default home directory at 3.

User accounts need configuration dotfiles (.shrc, .login, .profile, and so on). If you have a directory containing customized dotfiles, tell adduser about it at 4. Otherwise, just accept the default.

Though OpenBSD doesn’t include a welcome message by default, you can put one on the system so new users will have an email waiting for them on their first login. Give adduser the full path to the file containing your welcome message at 5.

Depending on how you create user accounts, you might want to provide a password when you create the user account. Accounts created without passwords are disabled until a password is assigned. If you won’t be assigning passwords when creating accounts, you can tell adduser not to prompt you for them at 6.

Finally, you can choose the encryption algorithm used to hash user passwords, which are stored in /etc/master.passwd. Unless you have specific interoperability needs or otherwise know what you’re doing, accept the default at 7.

From now on, adduser will use these chosen defaults. If you want to modify the defaults later on, change them in /etc/adduser.conf. Read the adduser(8) man page for a complete list of configuration file options.

Now that you’ve set your default options, run adduser again to create user accounts.

Start by assigning a username. Many people are irrationally attached to particular usernames, and it’s polite to ask them if they have a preference.

Ok, let's go.
Don't worry about mistakes. There will be a chance later to correct any input.
Enter username []: pkdick

Once you have a username, you’ll get a chance to enter the user’s real name or the account’s intended purpose.

Enter full name []: Phil Dick

The shell you specify is a matter of user preference. The list of shells is taken from /etc/shells, with the addition of the nologin option. Users can change their shell unless you specifically prevent that, so don’t worry too much about which shell you assign.

Enter shell csh ksh nologin sh tcsh [ksh]:

Next, choose a user ID (UID) number. By default, UID numbering starts at 1000, and adduser uses the lowest available number. You can change this if needed to match some local standard.

Uid [1001]:

By default, new users are assigned to a group with the same name as their username. Each user can be assigned to only a single login group (or primary group), but you can assign user accounts to multiple secondary groups if needed. If you want this user to be able to use the root account, invite the user to the wheel group. Other common groups include staff, users, and operator.

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

Choose a login class for the user. If you don’t understand login classes yet, accept the default. I recommend assigning administrative users—for example, those in the wheel group—to the staff class. If you’re a desktop user, you want to be in the staff login class.

Login class authpf bgpd daemon default staff [default]: staff

If you set adduser to ask for passwords, it will ask you for a password, and then ask again to confirm.

Enter password []:
Enter password again []:

Now adduser displays everything you selected.

Name:        pkdick
Password:    ****
Fullname:    Phil Dick
Uid:         1001
Gid:         1001 (pkdick)
Groups:      pkdick wheel
Login Class: staff
HOME:        /home/pkdick
Shell:       /bin/ksh
OK? (y/n) [y]: y

Either accept or reject the user at this point. If you accept, adduser will create the new user and ask if you want to create another user.

By default, new users are assigned a primary group with the same name as their login name. In batch mode, you must specify additional groups desired on the command line. Our example user pkdick is created with the login group of pkdick. If you want to set a different login group for a particular user, use the -group flag.

# adduser -group guest -batch jgballard customers 'Jim Ballard' NotThePassword

You’ll need to add the user to another group. Here, I gave jgballard the login group of guest and added him to the group customers.

To assign a user to multiple groups, separate the groups using commas.

# adduser -batch jgballard customers,sftp-only 'Jim Ballard' NotThePassword

The end result here is that jgballard is assigned to the jgballard primary group and added to the customers and sftp-only secondary groups.

If you actually follow any of the previous examples, you’ll create an account with no known password. Modern Unix-like operating systems don’t store passwords in readable format; instead, passwords are stored as a hash of the password and a random salt. When you assign a password to a user, the system takes the password, adds the salt, and performs some horrible computations to generate a hash of the password. The system then stores that hash and salt in the /etc/master.passwd file. When you attempt to log in, the login process takes your password, adds the salt, and computes the hash of that combination. If the computed hash matches what’s stored in /etc/master.passwd, the login is permitted.

The examples create an account with a password hash of NotThePassword. Because this isn’t a legitimate hash, no entered password will match it. We need to provide a pregenerated encrypted password, enter an unencrypted password, and let adduser calculate the hash for us, or create an account without a password.

Creating a new account without a password is the simplest option. OpenBSD will disable the account until you assign a password to it, but this is acceptable for accounts used to run daemons, or if you have a help desk staff to assist new users in setting passwords. To create an account without a password, simply omit the password from the account-creation process.

# adduser -batch pkdick wheel 'Phil Dick'

If you want to enter an unencrypted password on the command line, use the -unencrypted option. Put this option before the -batch option. For example, to give Phil’s account the password IsThePassword, enter the following:

# adduser -unencrypted -batch pkdick wheel 'Phil Dick' IsThePassword

This account now has a password of IsThePassword. You might use this inside a script or when no one is around to look over your shoulder. The password will appear in the system’s process list, however, so any users on the system can see the password if they’re quick enough to notice.

Another option is to generate a prehashed password using encrypt(1). By default, encrypt gives you a blank line. When you enter a word, it returns the hash of that word. It defaults to using the encryption algorithm defined in the default login class. (For the past several years, this has been Blowfish.) You can enter any number of words, and each will be hashed separately. Press CTRL-C to exit encrypt.

# encrypt
gerbil
$2a$06$V/VO91VVAKSNslesQNH6pezXsGhoKUMcnvWxyDOJUmWRk3fflX5cy
weasel
$2a$06$652ngShUnOBuFEL7X2yrf.E0U2GUw/FseVq/BkVgaiyqvp4wt.Nsy
^C
#

If you’re encrypting only one password or creating passwords interactively, give the -p option to encrypt. This gives you a non-echoing password prompt.

# encrypt -p
Enter string:
$2a$06$nyA.mygoei/6VGS2tq4wA.VOzB6inwlK9pWOIAsiUWBkWf0CqOJ7.
#

I frequently create administrator accounts with one set of standards and unprivileged accounts with another. I create sysadmin accounts by hand using adduser in interactive mode (I don’t create sysadmin accounts very often). Someone else creates unprivileged user accounts using an adduser batch mode script I wrote. adduser.conf contains the default settings for sysadmins, which I then override in the script. This approach requires less of my organic memory and ensures that unprivileged accounts are consistent.

All of these options must appear on the command line before the -batch argument. adduser treats everything after -batch as account information.

The -noconfig option tells adduser to not read defaults from adduser.conf. Using this option in a script guarantees that sysadmin-friendly defaults in adduser.conf don’t leak into unprivileged accounts.

The -dotdir option specifies a directory for user dotfiles. All files in this directory are copied to the new user’s home directory. I often have special dotfiles for unprivileged users.

The -home option tells adduser where to create the new user’s home directory. This is not the actual home directory, but the base directory where the home directory will be created. For example, if all of your web server customers have home directories on the /www partition, you might use -home /www.

To assign a nondefault login class, use the -class option.

The -message option gives a path to the new user message. To turn off a default of sending a message, use -message no.

To assign a shell, use -shell and the shell name as it appears in /etc/shells, or nologin to disable logins.

Perhaps you want to assign your batch-created users UIDs in a specific range. Maybe all of your customers have a UID above 10000, while sysadmins have a UID in the thousands. Specify a minimum UID with -uid_start and a maximum with -uid_end. If available, the login group created will be given a GID equal to the UID.