OpenBSD FAQ - General Questions [FAQ Index]



I forgot my root password

The basic process to regain root is to boot into single user mode, mount the relevant partitions (/ and /usr), run passwd(1) to change the root password. You can then boot and login normally.

The detailed process:

If this is a non-personal machine, you should probably use doas(1) 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(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.

The boot loader

When booting your OpenBSD system, you have probably noticed the boot prompt.
boot>
The OpenBSD boot loader is documented in the architecture-specific boot(8) man page.

If no commands are issued, the boot loader 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:

boot> boot hd0a:/bsd
This will boot the kernel named bsd from the a partition of the first BIOS recognized hard disk.

The following options are available.

The format is boot [image [-acds]].

ksh does not appear to read my .profile

There are two likely reasons for ksh(1) to seemingly ignore a user's .profile file.

Why is my clock off by twenty-some seconds?

When using rdate(8) to synchronize your clock to a NTP server, you may find your clock is off by twenty-some seconds from your local definition of time.

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.de
In other countries, the rules may differ.

Time zones

By default, OpenBSD assumes your hardware clock is set to UTC (Universal Coordinated Time) rather than local time, assumed by some other operating systems, which can cause problems when multibooting.

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):

# config -ef /bsd
[...]
Enter 'help' for information
ukc> timezone 300
timezone = 300, dst = 0
ukc> quit
Saving modified kernel.
See options(4) and search for option "TIMEZONE=value" for more information.

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:

# ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtime
See also:

Reverse DNS

Many new users to OpenBSD experience a two minute login delay when using services such as ssh(1) or ftp(1). This can also be experienced when using a proxy, such as ftp-proxy(8), or when sending mail.

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.

An example of this situation:

A user sets up an OpenBSD box as a firewall and gateway to their internal home network, mapping all their internal computers to one external IP using NAT. They may also use it as an outbound mail relay. They follow the installation guidelines, and are very happy with the results, except for one thing -- every time they try to attach to the box in any way, they end up with a two minute delay before things happen.

What is going on:

From a workstation behind the NAT of the gateway with an unregistered IP address of 192.168.1.35, the user uses ssh(1) to access the gateway system. The ssh(1) client prompts for username and password, and sends them to the gateway box. The gateway then tries to figure out who is trying to log in by performing a reverse DNS lookup of 192.168.1.35. The problem is 192.168.0.0 addresses are for private use, so a properly configured DNS server outside your network knows it should have no information about those addresses. Some will quickly return an error message. In these cases, OpenBSD will assume there is no more information to be gained, and it will quickly give up and just admit the user. Other DNS servers will not return ANY response. In this case, you will find yourself waiting for the OpenBSD name resolver to time out, which takes about two minutes before the login will be permitted to continue. In the case of ftp-proxy(8), some ftp clients will timeout before the reverse DNS query times out, leading to the impression that ftp-proxy isn't working.

This can be quite annoying. Fortunately, it is an easy thing to fix.

Fix, using /etc/hosts:

The simplest fix is as follows: Populate your hosts(5) file with all the workstations you have in your internal network. Make sure that your resolv.conf(5) file contains the line lookup file bind. This tells the resolver to start with the hosts(5) file, and failing that, to use the DNS servers specified by the nameserver lines in your resolv.conf(5) file.

Your /etc/hosts 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
Your /etc/resolv.conf file will look something like this:
search in.example.org
nameserver 24.2.68.33
nameserver 24.2.68.34
lookup file bind
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:
::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
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.

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.

Fix, using a local DNS server

Details on this are somewhat beyond the scope of this document, but the basic trick is to set up your favorite DNS server, and make sure it knows it is authoritative for both forward and reverse DNS resolution for all nodes in your network, and make sure your computers (including your gateway) know to use it as a DNS server.

Using S/Key

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 hash function: md5, sha1 or rmd160.
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.

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:
# skeyinit -E
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
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
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.

Generating S/Key passwords

To generate the S/Key password for the next login, use skeyinfo(1) to find out what command to run:
$ 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
In order to generate a list of S/Key passwords, do:
$ 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

Using S/Key to log in

Here is an example session using S/Key to log in to an ftp server on localhost. To perform an S/Key login, you append :skey to your login name.
$ 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.
Similarly, for ssh(1) or telnet(1):
$ 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 156.63.248.77
$

Device "not configured" in dmesg

In short, it means your device is not supported by the kernel you are using, so you will not be able to use it.

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:

[...]
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
[...]
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.

What can I do about a "not configured" device?

Unfortunately, many manufacturers use product model numbers to indicate marketplace position, rather than the technical nature of a product. For this reason, you may buy a product with the same name or model number as a product listed in the platform pages, but end up with a totally different product that may not work with OpenBSD.

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.