The detailed process:
At this point, enter boot -s to bring the system up in single user mode:probing: pc0 com0 com1 apm mem[636k 190M a20=on] disk: fd0 hd0+ >> OpenBSD/i386 BOOT 3.26 boot>
Most other platforms send parameters to the kernel via the boot ROM.boot> boot -s
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.
# fsck -p / && mount -uw / # fsck -p /usr && mount /usr
"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(8). Getting around those tricks is also pretty easy. One way would be to boot from a CD or USB drive and edit (or replace) the 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.
For most people, you won't have to do anything here. It will automatically boot if no commands are given. But sometimes problems arise, or special functions are needed. That's where these options will come in handy. To start off, you should read through the boot(8) man page. Here we will go over the most commonly used commands for the bootloader.boot>
To start off, if no commands are issued, the bootloader will automatically try to boot /bsd. If that fails, it will try /obsd, and if that fails, it will try /bsd.old. You can specify a kernel by typing:
orboot> boot hd0a:/bsd
This will boot the kernel named bsd from the 'a' partition of the first BIOS recognized hard disk.boot> b /bsd
Here is a brief list of options you can use with the OpenBSD kernel.
These are entered in the format of: boot [ image [-acds]]
For further information you can read boot(8).
# chown username ~username/.profile
Under xterm(1), argv for ksh(1) is not prepended with a dash. Prepending a dash to argv will cause csh(1) and ksh(1) to know they should interpret their login files. For csh(1) that's .login, with a separate .cshrc that is always run when csh(1) starts up. With ksh(1), this is more noticeable because there is only one startup script, .profile. This file is ignored unless the shell is a login shell.
To fix this, add the line XTerm*loginShell: true to the file .Xdefaults in your home directory. Note, this file does not exist by default, you may have to create it.
You may not have had to do this on other systems, as some installations of the X Window System come with this setting as default. OpenBSD has chosen to follow the X.org behavior.$ echo "XTerm*loginShell: true" >> ~/.Xdefaults
This is caused by a difference between UTC (Coordinated Universal Time, based on astronomical observations) and TAI (International Atomic Time, based on atomic clocks). To compensate for variations in the earth's rotation, "leap seconds" are inserted into UTC, but TAI is unadjusted. These leap seconds are the cause of this discrepancy. For a more detailed description, search the web for leap seconds UTC TAI.
Addressing the problem is fairly simple. In most countries you will get the correct time if you use the -c parameter to rdate(8) and use a time zone out of the directory /usr/share/zoneinfo/right. For example, if you are located in Germany, you could use these commands:
# cd /etc && ln -sf /usr/share/zoneinfo/right/CET localtime # rdate -ncv ptbtime1.ptb.deIn other countries, the rules may differ.
Many other operating systems can be configured to do the same, which avoids this problem altogether.
If having the hardware clock set to UTC is a problem, you can change the default behavior of OpenBSD using config(8). For example, to configure OpenBSD to use a hardware clock set to US/Eastern (5 hours behind UTC, so 300 minutes):
See options(4) and search for option "TIMEZONE=value" for more information.# config -ef /bsd [...] Enter 'help' for information ukc> timezone 300 timezone = 300, dst = 0 ukc> quit Saving modified kernel.
Normally, the time zone is set during install. If you have need to change the time zone, you can create a new symbolic link to the appropriate time zone file in /usr/share/zoneinfo. For example, to set the machine to use EST5EDT as the new local time zone:
See also:# ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtime
This is almost always due to a reverse-DNS problem. DNS is the Domain Name Service, the system the Internet uses to convert a name, such as "www.openbsd.org", into a numeric IP address. Another task of DNS is the ability to take a numeric address and convert it back to a name. This is known as a Reverse DNS entry.
In order to provide better logging, OpenBSD performs a reverse DNS lookup on any machine that attaches to it in many different ways, including ssh(1), ftp(1), ftp-proxy(8). Unfortunately, in some cases, the machine that is making the connection does not have a proper reverse DNS entry.
This can be quite annoying. Fortunately, it is an easy thing to fix.
Your /etc/hosts file will look something like this:
Your /etc/resolv.conf file will look something like this:::1 localhost.in.example.org localhost 127.0.0.1 localhost.in.example.org localhost 192.168.1.1 gw.in.example.org gw 192.168.1.20 scrappy.in.example.org scrappy 192.168.1.35 shadow.in.example.org shadow
A common objection to this is "But, I use DHCP for my internal network! How can I configure my /etc/hosts?" Rather easily, actually. Just enter lines for all the addresses your DHCP server is going to give out, plus any static devices:search in.example.org nameserver 22.214.171.124 nameserver 126.96.36.199 lookup file bind
This case assumes you have the DHCP range set to 192.168.1.100 through 192.168.1.199, plus the three static definitions as listed at the top of the file.::1 localhost.in.example.org localhost 127.0.0.1 localhost.in.example.org localhost 192.168.1.1 gw.in.example.org gw 192.168.1.20 scrappy.in.example.org scrappy 192.168.1.35 shadow.in.example.org shadow 192.168.1.100 d100.in.example.org d100 192.168.1.101 d101.in.example.org d101 192.168.1.102 d102.in.example.org d102 [... snip ...] 192.168.1.198 d198.in.example.org d198 192.168.1.199 d199.in.example.org d199
If your gateway must use DHCP for configuration, you may well find you have a problem -- dhclient(8) will overwrite your /etc/resolv.conf every time the lease is renewed, which will remove the lookup file bind line. This can be solved by putting the line lookup file bind in the file /etc/resolv.conf.tail.
WARNING: One-time password systems only protect authentication information. They do not prevent network eavesdroppers from gaining access to private information. 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.
Then use skeyinit(1) 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 otp-md5(1), 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.$ skeyinit Reminder - Only use this method if you are directly connected or have an encrypted channel. If you are using telnet, exit with no password and use skeyinit -s. Password: [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
In order to generate a list of S/Key passwords, do:$ skeyinfo -v otp-md5 95 oshi45820 $ otp-md5 95 oshi45820 Reminder - Do not use this program while logged in via telnet. Enter secret passphrase: NOOK CHUB HOYT SAC DOLE FUME
$ otp-md5 -n 5 95 oshi45820 Reminder - Do not use this program while logged in via telnet. 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
Similarly, for ssh(1) or telnet(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. ftp> quit 221 Goodbye.
$ 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 188.8.131.52 $
PCI and many other types of devices offer identifying information so that the OS can properly recognize and support devices. Adding recognition is easy, adding support is often not. Here are two examples of "not configured" devices:
The first one (a network adapter) had its vendor code identified and the general type of card was determined, but not the precise model of the card. The second example is another network adapter, this one a developer had seen and entered into the identification file that is used to identify the card. In both cases, however, the cards will be non-functional, as both are shown as not configured, meaning no driver has attached to the card.[...] vendor "Intel", unknown product 0x5201 (class network subclass ethernet, rev 0x03) at pci2 dev 9 function 1 not configured [...] "Intel EE Pro 100" rev 0x03 at pci2 dev 10 function 0 not configured [...]
For example, many early wireless network adapters were based on the Prism2 chipset, using the wi(4) driver, but later, when lower-cost chips became available, many manufacturers changed their product to use chips for which no open source drivers exist, but never changed their model numbers. Wireless network adapters, unfortunately, are far from the only example of this.