Install OpenBSD on a VPS or Cloud Server

Synopsis #

A virtual private server can install OpenBSD when the provider offers a supported architecture, compatible virtual devices, persistent storage, and a usable console or rescue path. The provider may supply an OpenBSD image, permit a custom ISO, or allow the OpenBSD ramdisk kernel to be booted from an existing rescue environment.

This guide describes the common workflow without endorsing a provider or reproducing a provider control panel. Record the provider’s current network and recovery requirements before changing the boot disk.

Confirm Required Provider Capabilities #

Verify the following before purchasing or reinstalling the instance:

  • a processor architecture supported by OpenBSD;
  • virtual storage and network devices supported by the selected release;
  • an interactive console that remains available when guest networking fails;
  • a method to attach verified installation media or boot bsd.rd;
  • documented IPv4 and IPv6 addresses, prefix lengths, gateways, and any unusual route requirements;
  • a recovery or rescue method that does not depend on the installed SSH service.

A provider label such as KVM, cloud, or VPS does not establish the exact virtual devices. When possible, boot installation media and inspect dmesg(8) before erasing an existing system.

Preserve Network and Recovery Information #

Record all assigned network data outside the instance. Provider networks may use gateways outside the apparent prefix, link-local IPv6 gateways, or routes installed by platform-specific metadata. Do not translate another operating system’s configuration mechanically into OpenBSD files without understanding those requirements.

Also record:

  • instance and account identifiers;
  • console access procedure;
  • boot-order controls;
  • attached volumes and which one will be erased;
  • DNS and reverse-DNS controls;
  • provider firewall rules, if present;
  • the expected SSH host name or address.

Provider firewall rules and OpenBSD PF rules form separate policy layers. A connection must be allowed by both.

Select an Installation Method #

Use one of these methods, in order of simplicity:

  1. Attach the official OpenBSD installation ISO through the provider’s virtual-media interface.
  2. Boot the official OpenBSD bsd.rd ramdisk kernel through a supported bootloader or rescue environment.
  3. Use a provider-supplied OpenBSD image only when its origin, release, configuration, and update state can be established.

Download installation media from an official mirror and verify it as described in the installation chapter . A checksum without a verified signature detects accidental corruption but does not establish authenticity.

Install Through the Console #

Open the provider console before changing the boot disk. Boot the verified media and confirm that the intended disk and network interface appear. Follow the standard installer.

For static networking, enter the provider-supplied address, prefix or netmask, gateway, and DNS information. If the provider requires a gateway outside the assigned prefix or another special route, complete the install with console access and configure the documented route before relying on SSH.

Use the automatic OpenBSD disk layout unless a workload requires a documented alternative. Install all sets for a general-purpose server. Set a strong temporary root password even when key-based administrative access will be configured immediately after installation.

Establish Administrative Access #

After the first disk boot, complete the first 30 minutes . Create a regular administrator account and install an SSH public key in that account’s ~/.ssh/authorized_keys file. Set ownership and permissions before testing the login.

# install -d -o admin -g admin -m 700 /home/admin/.ssh
# install -o admin -g admin -m 600 /tmp/admin.pub /home/admin/.ssh/authorized_keys

Replace admin and /tmp/admin.pub with the actual account and public-key source. Never transfer or store the private key on the server.

Test the new account from a separate client session. Confirm doas access before changing root or password authentication in sshd_config(5) . Validate SSH configuration with sshd(8) before reloading it.

# sshd -t
# rcctl reload sshd

Keep the provider console and the original SSH session open until a fresh key-based session succeeds.

Apply Network and PF Policy #

Write persistent interface configuration in the appropriate hostname.if(5) file. Confirm addresses and routes after a reboot:

$ ifconfig
$ route -n show
$ host openbsd.org

Create a minimal inbound PF policy for the services the instance actually provides. Validate changes with pfctl(8) while console access remains available.

# pfctl -nf /etc/pf.conf
# pfctl -f /etc/pf.conf

Do not assume the provider firewall replaces PF or that PF replaces the provider firewall. Document both layers.

Test Recovery Before Deployment #

Before adding application data:

  1. reboot from the installed disk;
  2. verify console access during boot;
  3. verify key-based SSH and doas;
  4. confirm IPv4, IPv6, routing, and DNS as applicable;
  5. attach or boot recovery media once without starting a reinstall;
  6. establish an independent backup destination;
  7. restore at least one test file.

Provider snapshots can shorten recovery, but they are not automatically filesystem-consistent and do not replace independently stored backups. Record the tested recovery procedure with the server inventory.

Report a bug