Hitchhiker's Guide to Openbsd

Boot into single user mode. This part of the process varies from 
platform
 to platform. For 
amd64 and i386 platforms, the 
second stage boot loader
, 
boot(8)
, pauses for a few seconds to 
give you a chance to provide parameters to the kernel. This prompt looks like this: 
probing: pc0 com0 com1 apm mem[636k 190M a20=on]
disk: fd0 hd0+
>> OpenBSD/i386 BOOT 3.15
boot>
At this point, enter "
boot -s
" to bring the system up in single user mode: 
boot> boot -s
Most other platforms send parameters to the kernel via the boot ROM. 
Of course the problem before this will probably be getting the system to shut down. Most likely, 
this will involve hitting the reset button or the power button. While hardly desirable, there usually 
isn't any alternative. Don't worry too much, OpenBSD's file system is very robust. 
●
Mount the partitions. Both "/" and 
/usr
will need to be mounted read-write. Assuming they 
are on separate partitions (as they should be), the following will work: 
# fsck -p / && mount -uw /
# fsck -p /usr && mount /usr
●
Run 
passwd(1)
 to change the root password. As you already have root privileges (from being 
in single-user mode), it will not ask you to provide your current password. 
●
boot into multiuser mode. This can be done by either entering "CTRL-D" to resume the normal 
boot process, or by entering the 
reboot(8)
command. 
If this is a non-personal machine, you should probably use 
sudo(8)
 to give multiple (trusted) people the 
ability to execute root commands. 
"Wait. That looked too easy! That isn't very secure!" If an attacker has physical access to your 
system, they win, regardless of the OS on the computer. There are ways to force the use of a password 
on single-user mode (see 
ttys(5)
), or eliminate the pause on i386/amd64 (see 
boot.conf
), but practically 
speaking, getting around those tricks is also pretty easy (One way: boot floppy or CDROM, edit or 
http://www.openbsd.org/faq/faq8.html (2 of 20)9/4/2011 10:02:10 AM

---

8 - General Questions
replace password file). You can try to prevent that, but then someone will pull the hard disk out of your 
computer. Making your computer difficult to manage properly isn't real security, and if you don't have 
the physical machine secured, you have no real security. 
Note: many "remote management" systems give most of the functionality of physical access to the 
computer, and that needs to be considered. Don't tell yourself the system is secure if there is a way for an 
attacker to grab console, insert a virtual floppy and force a reboot of the machine. They might as well 
have physical access to the system. The console management system is likely not as secure as 
OpenBSD...