OpenBSD First Boot Checklist

OpenBSD rewards a deliberate first hour. The base system is small, the defaults are conservative, and the tools are consistent — but a machine is not ready for unattended work just because it finished installing. This is the checklist I use before treating an OpenBSD host as a useful server, gateway, or field machine.

Confirm What You Installed

Before changing anything, record the release and hardware. It makes later troubleshooting much easier, especially when a driver or package behaves differently between releases:

$ uname -a
$ hostname
$ dmesg | less
$ sysctl kern.version

Write down the hostname, network interface names, disk layout, installation media, and the purpose of the machine. A short deployment note is often more useful than trying to reconstruct the setup months later.

Create an Administrative Account

Do not make routine SSH work depend on a direct root login. Create a named account, put it in the wheel group, and use OpenBSD's built-in doas for the occasional privileged command:

# Run these as root. adduser is interactive.
# adduser
# usermod -G wheel jason

# /etc/doas.conf
permit :wheel

Replace jason with the real account name. Keep the doas.conf rule simple at first. Once the account works, test doas from a second session before closing the root console.

Install Your SSH Key Before Hardening SSH

Use a key that is already backed up on your workstation. On the workstation, generate an Ed25519 key if you do not have one:

$ ssh-keygen -t ed25519 -C "jason@workstation"

For the first connection, copy the public key into the new account's authorized_keys. When a convenience command is not available on the workstation, the manual method works everywhere:

$ ssh jason@openbsd-host
$ mkdir -p ~/.ssh
$ chmod 700 ~/.ssh
$ vi ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys

Paste the contents of the workstation's id_ed25519.pub into that file. Open a second terminal and confirm that key login works before disabling password login.

Harden and Validate sshd

Edit /etc/ssh/sshd_config only after key authentication has been tested. The exact policy depends on how the machine is managed, but these are sensible starting points for an internet-facing host:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

If more than one person needs access, prefer an explicit AllowUsers or AllowGroups policy over sharing an account. Keep the second session open while validating the change:

# Check syntax before reloading.
# sshd -t

# Reload without unnecessarily dropping existing sessions.
# rcctl reload sshd

Do not turn off password authentication until you have a working key, a tested doas account, and a recovery path through the local console or out-of-band management.

Apply OpenBSD Updates

OpenBSD separates release upgrades from errata patches. Keep the installed release current with syspatch, and use sysupgrade deliberately when moving to a newer release. Packages are updated separately:

# Install the published binary errata for the current release.
# syspatch

# Review and update installed packages.
# pkg_add -u

# Inspect package and patch state.
# syspatch -l
# pkg_info

Read the release notes and upgrade documentation before using sysupgrade. A major or release upgrade is a maintenance event: make a backup, confirm console access, record third-party packages, and do not combine it with unrelated application changes.

Know Which Services Are Enabled

OpenBSD uses rcctl for service management. Check what is enabled rather than assuming an installed daemon is running:

# List services enabled at boot.
# rcctl ls on

# See available service names and current state.
# rcctl ls all
# rcctl status sshd

# Enable a service only when the machine needs it.
# rcctl enable ntpd
# rcctl start ntpd

Every extra listening service is another decision to document and maintain. On a small host, a short list of enabled daemons is usually a feature.

Check the Network Before You Leave the Console

# Replace em0 with the interface shown by dmesg or ifconfig.
$ ifconfig
$ route -n show
$ ping -c 3 192.0.2.1
$ ping -c 3 9.9.9.9
$ ping -c 3 openbsd.org

Test the local gateway, an address outside the local network, and DNS separately. If the first failure is DNS, there is no point debugging the firewall yet. Save the final interface and hostname configuration in the deployment notes.

Enable Only the Firewall Policy You Understand

OpenBSD's pf is powerful enough to lock you out with one careless rule. The companion article OpenBSD pf — The Packet Filter covers rule structure, tables, validation, and state handling. Start with a policy that describes the services you actually need, validate it, and keep a console or second session available while loading it:

# Validate without loading the ruleset.
# pfctl -nf /etc/pf.conf

# Inspect the active rules and states.
# pfctl -sr
# pfctl -ss

Do not paste a generic “deny everything” ruleset onto a remote machine without first allowing your administration path and confirming the interface names. Firewall changes should be reversible from the console.

Make a Small Maintenance Record

Before calling the host finished, record:

hostname, purpose, location, and responsible person
release, architecture, disk layout, and network interfaces
enabled services and the ports they expose
where backups live and how console recovery works
the last successful syspatch, package update, and restore test

The best OpenBSD setup is not the one with the most hardening pasted into a configuration file. It is the one whose owner knows what is running, can update it safely, and can recover it when the network or storage does something unexpected.