OpenBSD uses many of the standard UNIX user- and password-management programs, such as passwd(1)
and vipw(8)
. It also includes a friendly interactive user-creation program, adduser(8)
. We’ll cover adduser
first, and then look at some of the more advanced tools.
Only the root user can run adduser
. If you start adduser
at the command line without specifying any options, it drops you into a friendly interactive dialog where you can create new users.
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.
If you need to create many users, you probably don’t want to spend your day looping through adduser
dialogs. If you have scripts, cron jobs, or web interfaces that add user accounts, you’ll want to create users noninteractively. adduser
’s -batch
flag enables this. When you use batch mode, adduser
takes four additional arguments: the username, the groups the username belongs to, the full name, and the password in encrypted format.
# adduser -batch username group 'Real Name' encryptedpassword
To create our user pkdick
in batch mode, we would run this:
# adduser -batch pkdick wheel 'Phil Dick' NotThePassword
One thing to note here is that pkdick
’s password is not NotThePassword
. adduser
expects us to provide a random salt that hashes to the string NotThePassword
, not the password itself. For instructions on how to generate encrypted passwords, see Passwords and Batch Mode.
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.
User accounts are subject to the following restrictions, fully documented in adduser(8)
.
Usernames can contain characters (preferably lowercase) and digits, as well as nonleading hyphens, periods, underscores, and a trailing $
. Usernames can be no longer than 31 characters.
Full names cannot contain a colon (:
).
Other values must exist in the relevant files: shells must appear in /etc/shells, login classes in /etc/login.conf, and so on.