When a critical bug is found, the fix will be committed to the -current tree
as soon as possible.
From that point on, things are handled differently depending on whether the
problem was in the OpenBSD base system or a third party package.
This section details how to keep your system up to date between releases.
For the OpenBSD base system, there are four options:
For third party software installed via packages,
there are two options:
- Apply binary patches
If you're running a supported release of OpenBSD, you can simply use
the syspatch(8) utility
to upgrade any files in need of security or reliability fixes.
This is the quickest and easiest method to get the base system up to date.
Note that binary patches are only available for the amd64, i386, and arm64
- Update your system to -stable
Fetch (or update) your source tree with CVS,
then recompile the kernel and userland.
- Patch the affected files individually
While applying fixes from the errata page
typically requires less time than a CVS checkout/update and rebuild,
there is no universal set of instructions to follow.
Sometimes you must patch and recompile one application, sometimes more.
- Upgrade your system to -current
As all fixes are applied to the -current code base, updating your system
to the latest snapshot is a good way to
get all the fixes at once.
However, running -current is not for everyone.
- Upgrade your system to -current and use binary packages
Binary packages for -current snapshots are rebuilt on a regular basis,
and these new packages will include any security fixes that were committed.
Simply call pkg_add(1) with
the -u flag after picking a mirror
to get the new files.
- Use the -stable ports tree
Fetch (or update) your ports tree with CVS,
run the /usr/ports/infrastructure/bin/out-of-date script to
list any packages that need rebuilding, and issue make update
in the affected port directory.
Alternatively, packages can be built in bulk with
To be alerted of port updates, consider following the "ports-changes"
System daemons (or "services") are started, stopped and controlled by
the rc(8) script via
All system daemons, and most add-on packages, are
handled this way.
Most daemons and services that come with OpenBSD are controlled on boot
by variables defined in
You'll see lines similar to this:
This shows that httpd(8) is not to
be started from rc(8) at boot time.
Each line has a comment showing you the flags for common usage of that daemon
Do not alter rc.conf(8) directly.
Instead, use the rcctl(8) utility
to maintain the /etc/rc.conf.local file.
This makes future upgrades easier -- all the changes are in the one file that
isn't touched during upgrade.
For example, to start the apmd(8)
daemon for CPU scaling, you might do:
# rcctl enable apmd
# rcctl set apmd flags -A
# rcctl start apmd
Executing commands as another user
One challenge system administrators face is the contradictory requirement
of multiple people managing machines using logins that shouldn't be shared.
The doas(1) tool can solve this
problem by permitting a certain subset of users to run predetermined commands
as another user.
Regular users can run administrative commands, only needing to authenticate
as themselves, rather than needing the root password.
For example, if appropriately configured, the following command would display
root's crontab(5) file:
All commands are logged to /var/log/secure.
Check the doas.conf(5) manual
for configuration examples.
$ doas crontab -l -u root
Editing the password file
The main password file is /etc/master.passwd, which is only readable
The pwd_mkdb(8) utility generates
the publicly readable /etc/passwd file and the password databases
/etc/pwd.db and /etc/spwd.db from /etc/master.passwd.
The file format is described in
Always use vipw(8) to edit your
vipw(8) will invoke your $EDITOR to edit a copy of /etc/master.passwd.
After you are done editing, vipw(8) will first sanity check your changes, then
it will re-create /etc/passwd and the password databases, and finally
it will install the copy in place of the original /etc/master.passwd
vipw(8) also takes care of locking these files, so that only one user can make
changes at a time.
S/Key is a "one-time password" authentication system.
It generates a sequence of one-time (single use) passwords from a user's
secret passphrase along with a challenge received from the server, by means of a
One-time password systems only protect authentication information.
They do not prevent network eavesdroppers from gaining access to private
Furthermore, if you are accessing a secure system A, it is recommended that
you do this from another trusted system B, to ensure nobody is gaining access
to system A by logging your keystrokes or by capturing and/or forging input
and output on your terminal devices.
Setting up S/Key
To start off, the directory /etc/skey must exist.
If this directory doesn't exist, have the superuser create it by doing:
to initialize your S/Key.
You will first be prompted for your login password, then you will be asked for
your S/Key secret passphrase, which must be at least 10 characters long:
# skeyinit -E
Notice the information in the last two lines.
The program used to create your S/Key password is
the sequence number is 100 and the secret key is oshi45820.
The six small words HAUL BUS JAKE DING HOT HOG constitute the S/Key
password with sequence number 100.
[Adding ericj with md5]
Enter new secret passphrase:
Again secret passphrase:
ID ericj skey is otp-md5 100 oshi45820
Next login password: HAUL BUS JAKE DING HOT HOG
Generating S/Key passwords
To generate the S/Key password for the next login, use
to find out what command to run:
In order to generate a list of S/Key passwords, do:
$ skeyinfo -v
otp-md5 95 oshi45820
$ otp-md5 95 oshi45820
Enter secret passphrase:
NOOK CHUB HOYT SAC DOLE FUME
$ otp-md5 -n 5 95 oshi45820
Enter secret passphrase:
91: SHIM SET LEST HANS SMUG BOOT
92: SUE ARTY YAW SEED KURD BAND
93: JOEY SOOT PHI KYLE CURT REEK
94: WIRE BOGY MESS JUDE RUNT ADD
95: NOOK CHUB HOYT SAC DOLE FUME
Using S/Key to log in
Here is an example session using S/Key to log in to an ftp server on
To perform an S/Key login, you append :skey to your login name.
Similarly, for ssh(1):
$ ftp localhost
Connected to localhost.
220 oshibana.shin.ms FTP server (Version 6.5/OpenBSD) ready.
Name (localhost:ericj): ericj:skey
331- otp-md5 93 oshi45820
331 S/Key Password: JOEY SOOT PHI KYLE CURT REEK
230 User ericj logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
$ ssh -l ericj:skey localhost
otp-md5 91 oshi45821
S/Key Password: SHIM SET LEST HANS SMUG BOOT
Last login: Thu Apr 7 12:21:48 on ttyp1 from 220.127.116.11
OpenBSD can be used for both servers and clients of databases containing
user credentials, group information and other network-related data.
Which directory services are available?
Of course, you could use various directory services on OpenBSD.
But YP is the only one that can be accessed directly using standard
C-library functions like
and so on.
Thus, if you keep your data in a YP database, you do not need to copy it to
local configuration files like
master.passwd(5) before you
can use it, for example to authenticate system users.
YP is a directory service compatible with Sun Microsystems NIS
(Network Information System).
See yp(8) for an overview of the
available manual pages.
Be careful, some operating systems contain directory services bearing similar
names but all the same being incompatible, for example NIS+.
To use directory services other than YP, you either need to populate local
configuration files from the directory, or you need a YP frontend to
For example, you can use the sysutils/login_ldap port when you choose
the former, while the ypldap(8)
daemon provides the latter.
For some applications, simply synchronizing a small number of configuration
files among a group of machines using tools like
rsync (available from ports) constitutes an easy and robust alternative
to a full-blown directory service.
YP security considerations
For compatibility reasons, all security features built into the OpenBSD
implementation of YP are switched off by default.
Even when they are all switched on, the NIS protocol is still inherently
insecure for two reasons:
All data, including sensitive data like password hashes, is transmitted
unencrypted across the network, and neither the client nor the server can
reliably verify each other's identity.
Thus, before setting up any YP server, you should consider whether these
inherent security flaws are acceptable in your context.
In particular, YP is inadequate if potential attackers have physical access
to your network.
Anybody gaining root access to any computer connected to your network segments
carrying YP traffic can bind your YP domain and retrieve its data.
In some cases, passing YP traffic through SSL or IPSec tunnels might be
Setting up a YP server
A YP server serves a group of clients called a "domain."
You should first select a domain name; it can be an arbitrary string and
need not be related in any way to DNS domain names.
Choosing a random name like "Eepoo5vi" can marginally improve security,
though the effect is mostly in security by obscurity.
In case you need to maintain several distinct YP domains, it's probably
better to choose descriptive names like "sales," "marketing" and "research"
in order to forestall system administration errors caused by obscurity.
Also note that some versions of SunOS require using the host's DNS domain
name, so your choice might be restricted in a network including such hosts.
Use the domainname(1)
utility to set the domain name, and put it into the
file to have it automatically set at system startup time.
# echo "puffynet" > /etc/defaultdomain
# domainname `cat /etc/defaultdomain`
Initialise the YP server using the interactive command
At this point, it is not necessary to specify slave servers yet.
To add slave servers, you can rerun
later, using the -u option.
Setting up at least one slave server for each domain is useful to avoid
For example, should the master server ever go down or lose network
connectivity, client processes trying to access YP maps block indefinitely
until they receive the requested information.
Thus, YP service interruptions typically render the client hosts completely
unusable until YP is back to service.
# ypinit -m
Decide where to store the source files to generate your YP maps from.
Keeping the server configuration separate from the served configuration
helps to control which information will be served and which won't, so the
default /etc often isn't the best choice.
The only inconvenience caused by changing the source directory is that you
will not be able to add, remove and modify users and groups in the
YP domain using utilities like
Instead, you will have to edit the configuration files with a text editor.
To define the source directory, edit the file
and change the DIR variable, e.g.
Consider customizing other variables in
For example, even in case you use the default source directory
/etc, you do not usually need all accounts and groups existing
on the server on all your client hosts.
In particular, not serving the root account and thus keeping root's password
hash confidential is often beneficial to security.
Review the values of MINUID, MAXUID, MINGID
and MAXGID and adjust them to you needs.
If all your YP clients run OpenBSD or FreeBSD, exclude the encrypted
passwords from the passwd maps by setting UNSECURE="" in
The former practice of editing the template file
/var/yp/Makefile.yp is no longer recommended.
Changes to that file affect all domains initialized after the change, but
do not affect domains initialized before the change, so this is error-prone
You both risk that the intended changes do not take effect, and you risk to
forget about them and have them affect other domains later which they were
never intended for.
Create the source directory and populate it with the configuration files
to learn which YP maps require which source files.
For the format of the individual configuration files, refer to
and so on, and look at the examples in /etc.
Create the initial version of your YP maps using the commands
Do not worry about error messages from
yppush(8) right now.
The YP server is not yet running.
# cd /var/yp
YP uses rpc(3)
(remote procedure calls) to communicate with clients, so it is necessary
to enable portmap(8).
To do so, use rcctl(8).
# rcctl enable portmap
# rcctl start portmap
Consider using either the
securenet(5) or the
security feature of the YP server daemon.
But be aware that both of these only provide IP based access control.
Thus, they only help as long as potential attackers have neither physical
access to the hardware of the network segments carrying your YP traffic
nor root access to any host connected to those network segments.
Finally, start the YP server daemon:
# rcctl enable ypserv
# rcctl start ypserv
To test the new server, consider making it its own client,
following the instructions in the first part of the next section.
In case you don't want the server to use its own maps, you can
disable the client part after the test with the following commands:
# rcctl stop ypbind
# rcctl disable ypbind
Remember that each time you change a file sourced by a YP map,
you must regenerate your YP maps.
This updates all database files in /var/yp/`domainname`, with
one exception: The file ypservers.db, listing all YP master
and slave servers associated with the domain, is created directly
from ypinit -m and modified exclusively by ypinit -u.
In case you accidentally delete it, run ypinit -u to recreate
it from scratch.
# cd /var/yp
Setting up a YP client
Setting up a YP client involves two distinct parts.
First, you must get the YP client daemon running,
binding your client host to a YP server.
Completing the following steps will allow you to retrieve data
from the YP server, but that data will not yet be used by the system:
The second part of configuring a YP client involves editing local configuration
files such that certain YP maps get used by various system facilities.
Not all servers serve all standard maps supported by the operating system, some
servers serve additional non-standard maps, and you are by no means compelled to
use all those maps.
Which of the available maps shall or shall not be used, and for which purposes
they shall be used, is fully at the discretion of the client host's system
Like on the server, you must set the domain name and enable the portmapper:
# echo "puffynet" > /etc/defaultdomain
# domainname `cat /etc/defaultdomain`
# rcctl enable portmap
# rcctl start portmap
It is recommended to provide a list of YP servers in the configuration
Otherwise, the YP client daemon will use network broadcasts to find
YP servers for its domain.
Explicitly specifying the servers is both more robust and marginally
less open to attack.
If you have not set up any slave servers, just put the host name
of the master server into /etc/yp/`domainname`.
Enable and start the YP client daemon,
# rcctl enable ypbind
# rcctl start ypbind
If all went well you should be able to query the YP server using
and see your passwd map returned.
Another useful tool for debugging your YP setup is
# ypcat passwd
For a list of standard YP maps and their standard usage, see
The most common use cases include:
If you want to include all user accounts from the YP domain, append the
default YP marker to the master password file and rebuild the password
For details on selective inclusion and exclusion of user accounts, see
To test whether inclusion actually works, use the
# echo '+:*::::::::' >> /etc/master.passwd
# pwd_mkdb -p /etc/master.passwd
If you want to include all groups from the YP domain, append the default YP
marker to the group file:
For details on selective group inclusion, see
# echo '+:*::' >> /etc/group