![[OpenBSD]](../images/smalltitle.gif){kind=small}
[FAQ Index] [To Section 7 - Keyboard and Display controls] [To Section 9 - Migrating to OpenBSD]
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.17 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), but practically speaking, getting around those tricks is also pretty easy (One way: boot floppy or CDROM, edit or 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...
A common cause for X problems is the machdep.allowaperture sysctl(8) setting. Since this defaults to being disabled on OpenBSD, this is a fairly likely cause of the problem.
You need to edit /etc/sysctl.conf and set machdep.allowaperture=2 (or 1, depending upon your platform). This will allow X to access the aperture driver, xf86(4), upon the next reboot. It can not be made available after boot. This can also be set during install if you answer "Y" when you are asked whether you expect to run the X Window System.
OpenBSD requires that the aperture driver be activated on alpha, amd64, i386, macppc and sparc64 platforms to control access to the video boards. Other platforms use a safer way to handle the video system, and do not need this (and do not have it in their kernel). If you do not anticipate using X on your system, it is recommended that you not enable the aperture driver.
For more information about configuring and using X on your platform, see the /usr/X11R6/README file on your installed system.
The following table attempts to give an overview of compilers for different languages, where you can find them, and whether there are any issues or limitations with them. Some of these are limited to certain platforms. This can be seen either by examining a search result through the ports tree, and noting what is mentioned in "Archs", or by inspecting the port's Makefile directly. In the latter case, look for lines containing ONLY_FOR_ARCHS, NOT_FOR_ARCHS, BROKEN, etc.
Note: For ease of use, this article provides an alphabetical list, without distinguishing between different categories of programming languages. This is not a comprehensive list of everything that is available or can be used on OpenBSD. If you feel there are inaccuracies or issues which are not mentioned here, feel free to report that.
| Language | Where? | Notes |
| Awk | base54.tgz, awk(1) | |
| lang/gawk | GNU awk | |
| C, C++ | comp54.tgz, gcc(1) | The C/C++ compilers in the base system have been audited and they have several security enhancements (e.g. ProPolice) enabled by default. Please see gcc-local(1) for details. They will also emit warnings when using unsafe functions such as sprintf(), strcpy(), strcat(), tmpnam(), etc. Most platforms use gcc 4.2.1. |
| lang/gcc devel/llvm | These compilers have not gone through the security audit and do not contain security enhancements like those in the base system. The gcc binaries are renamed egcc, eg++, etc. to avoid confusion with their counterparts in the base system. | |
| Caml | lang/ocaml | Objective Caml |
| COBOL | lang/open-cobol | |
| Erlang | lang/erlang | |
| Fortran | lang/g77 | Only Fortran 77 support. |
| lang/gcc | Fortran 95 is also supported by egfortran in gcc 4.0 and above. This new compiler is available as a subpackage (f95) of gcc. | |
| Haskell | lang/ghc | |
| lang/nhc98 | ||
| Java | devel/jdk | Sun JDK - only 1.7 as a package; 1.6 is not recommended due lack of updates and restrictive license. |
| www/icedtea-web | Browser plugin and web start for jdk/1.7 only. | |
| devel/eclipse | Large IDE; works with Sun JDK. | |
| devel/netbeans | Another IDE; works with Sun JDK. | |
| Lisp | lang/clisp | |
| Lua | lang/lua | Additional Lua libraries and auxiliary utilities are available in the ports tree. |
| Perl | base54.tgz, perl(1) | Many Perl modules are available in the ports tree, so search there first before installing modules from CPAN. |
| Perl 6 | lang/rakudo | |
| PHP | lang/php | Plenty of subpackages are available for different PHP modules. |
| Prolog | lang/gprolog | GNU Prolog compiler. |
| lang/swi-prolog | SWI-Prolog environment. | |
| Python | lang/python | Other ports are using Python 2.7 by default. |
| Ruby | lang/ruby | |
| Scheme | lang/chicken | |
| lang/scheme48 | ||
| lang/scm | ||
| shells/scsh | ||
| Smalltalk | lang/squeak | |
| Tcl | lang/tcl |
You need to set the kernel to always assume the floppy is attached, even if not detected during the hardware probe, by setting the 0x20 flag bit on fdc(4). This can be done by using User Kernel Config or config(8) to alter your kernel,
# config -e -f /bsd
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Enter 'help' for information
ukc> change fd*
254 fd* at fdc0 drive -1 flags 0x0
change [n] y
drive [-1] ? ENTER
flags [0] ? 0x20
254 fd* changed
254 fd* at fdc0 drive -1 flags 0x20
ukc> q
Saving modified kernel.
#
When booting your OpenBSD system, you have probably noticed the boot prompt.
boot>
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 common used commands for the bootloader.
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 hand by typing:
orboot> boot hd0a:/bsd
boot> b /bsd
This will boot the kernel named bsd from the 'a' partition of the first BIOS recognized hard disk.
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 reading you can read boot(8)'s man page.
S/Key is a ``one-time password'' authentication system. It can be useful for people who don't have the ability to use an encrypted channel which protects their authentication credentials in transit, as can be established using ssh(1).
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.
The S/Key system 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 secure hash function. The system is only secure if the secret passphrase is never transferred over the network. Therefore initializing or changing your secret passphrase MUST be done over a secure channel, such as ssh(1) or the console.
OpenBSD's S/Key implementation can use a variety of algorithms as the one-way hash function. The following algorithms are available:
To start off the directory /etc/skey must exist. If this directory is not in existence, have the super-user create it. This can be done simply by doing:
# skeyinit -E
Once that directory is in existence, you can initialize your S/Key. To do this you must use skeyinit(1). Since skeyinit(1) will be asking you for your S/Key secret passphrase, you must run this over a secure channel, as explained above! The program will even remind you of this. With skeyinit(1), you will first be prompted for your password to the system. This is the same password that you used to log into the system. Once you have authorized yourself with your system password, you will be asked for your S/Key secret passphrase. This is NOT your system password. Your secret passphrase must be at least 10 characters. We suggest using a memorable phrase containing several words as the secret passphrase. Here is an example user being added.
$ 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
One line of particular importance in here is ID ericj skey is otp-md5 100 oshi45820. This gives a lot of information to the user. Here is a breakdown of the sections and their importance.
But of more immediate importance is your one-time password. Your one-time password consists of 6 small words, combined together this is your one-time password, spaces and all. The one-time password printed by skeyinit cannot be used to login (there is a usage for this first one-time password, see skeyinit(1)). To be able to log in, a one-time password corresponding to the challenge printed by the login process has to be computed using skey(1). The next section will show how to do that.
By now your skey has been initialized. You're ready to login. Here is an example session using S/Key to login. 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 96 oshi45820 331 S/Key Password: 230- OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 230- 230- Welcome to OpenBSD: The proactively secure Unix-like operating system. 230- 230- Please use the sendbug(1) utility to report bugs in the system. 230- Before reporting a bug, please try to reproduce it with the latest 230- version of the code. With bug reports, please try to ensure that 230- enough information to reproduce the problem is enclosed, and if a 230- known fix for it exists, include that as well. 230- 230 User ericj logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> quit 221 Goodbye.
Note that I appended ":skey" to my username. This tells ftpd that I want to authenticate using S/Key. Some of you might have noticed that my sequence number has changed to otp-md5 96 oshi45820. This is because by now I have used S/Key to login several times. But how do you get your one-time password? Well, to compute the one-time password, you'll need to know what sequence number you're using and your key. As you're probably thinking, how can you remember which sequence number you're on?
When you are logging in, the login process prints a line containing the needed information, which you can use to generate a one-time password on the spot using another trusted computer accesses by a secure channel, by copy-pasting the line into a command shell:
otp-md5 96 oshi45820
After typing your passphrase, your one-time password will be printed, which you can then copy-paste to the S/Key Password prompt to log in. Not only is otp-md5 a description of the hash used, it is also an alternate name for the skey(1) command.
If you already are logged in and want to generate a one-time password for the next login, use skeyinfo(1), it will tell you what to use for the next login. For example here, I need to generate another one-time password for a login that I might have to make in the future. (remember I'm doing this from a secure channel).
$ skeyinfo 95 oshi45820
An even better way is to use skeyinfo -v, which outputs a command suitable to be run in the shell. For instance:
$ skeyinfo -v otp-md5 95 oshi45820
So, the simplest way to generate the next S/Key password is just:
$ `skeyinfo -v` Reminder - Do not use this program while logged in via telnet. Enter secret passphrase: NOOK CHUB HOYT SAC DOLE FUME
Note the backticks in the above example.
I'm sure many of you won't always have a secure connection or a trusted local computer to create these passwords, and creating them over an insecure connection isn't feasible, so how can you create multiple passwords at one time? You can supply skey(1) with a number of how many passwords you want created. This can then be printed out and taken with you wherever you go.
$ 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
Notice here though, that the bottom password should be the first used, because we are counting down from 100.
Using S/Key with ssh(1) or telnet(1) is done in pretty much the same fashion as with ftp--you simply tack ":skey" to the end of your username. Example:
$ ssh -l ericj:skey localhost otp-md5 98 oshi45821 S/Key Password: SCAN OLGA BING PUB REEL COCA Last login: Thu Apr 7 12:21:48 on ttyp1 from 156.63.248.77 OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. You have mail. $
SMP is supported on the OpenBSD/i386, OpenBSD/amd64, OpenBSD/mvme88k, OpenBSD/sparc64 (including the UltraSPARC T1/T2/T2+ processors), OpenBSD/macppc, OpenBSD/sgi (Octane only), and OpenBSD/hppa platforms.
A separate SMP kernel, "bsd.mp", is provided with the install file sets. If multiple processors are detected at install time, is automatically installed as the default boot kernel, /bsd, and the single processor kernel is renamed /bsd.sp.
If you add additional processors to a system which was installed with only one processor, you will want to install the appropriate bsd.mp kernel, rename your existing /bsd to /bsd.sp, and rename /bsd.mp to /bsd.
It is hoped that other SMP-capable platforms will be supported in the future. On most other platforms, OpenBSD will run on an SMP system, but only utilizing one processor. The exception to this is the SPARC platform -- OpenBSD/sparc will sometimes require that extra MBus modules be removed for the system to boot.
You need to use /dev/cuaXX for connections initiated from the OpenBSD system, the /dev/ttyXX devices are intended only for terminal or dial-in usage. While it was possible to use the tty devices in the past, the OpenBSD kernel is no longer compatible with this usage.
From cua(4):
For hardware terminal ports, dial-out is supported through matching device nodes called calling units. For instance, the terminal called /dev/tty03 would have a matching calling unit called /dev/cua03. These two devices are normally differentiated by creating the calling unit device node with a minor number 128 greater than the dial-in device node. Whereas the dial-in device (the tty) normally requires a hardware signal to indicate to the system that it is active, the dial-out device (the cua) does not, and hence can communicate unimpeded with a device such as a modem. This means that a process like getty(8) will wait on a dial-in device until a connection is established. Meanwhile, a dial-out connection can be established on the dial-out device (for the very same hardware terminal port) without disturbing anything else on the system. The getty(8) process does not even notice that anything is happening on the terminal port. If a connecting call comes in after the dial-out connection has finished, the getty(8) process will deal with it properly, without having noticed the intervening dial-out action.
Lynx, a text-based browser, is in the base system, and has SSL support. Other browsers available include (in no particular order):
Graphical (X) Browsers
Console (Text mode) Browsers
Most of the abovementioned browsers are available as pre-compiled packages on the FTP servers, with some also on the CD-ROM. After the installation of the ports tree, all can also be found in the /usr/ports/www/ directory.
As most of the graphical browsers are very large and require quite some time to download and compile, one should seriously consider the use of packages where available.
mg(1) is a micro Emacs-style text editor included in OpenBSD. Micro means that it's a small implementation which is mostly similar to the text editor features of GNU Emacs. It does not implement many of Emacs' other features (including mail and news functionality, as well as modes for Lisp, C++, Lex, Awk, Java, etc...).
A concise tutorial is included with OpenBSD (located at /usr/share/doc/mg/tutorial).
There are two likely reasons for ksh(1) to seemingly ignore a user's .profile file.
# chown username ~username/.profile
Under xterm(1), argv[0] for ksh(1) is not prepended with a dash ("-"). Prepending a dash to argv[0] 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.
$ echo "XTerm*loginShell: true" >> ~/.Xdefaults
You may not have had to do this on other systems, as some installations of X Window System come with this setting as default. OpenBSD has chosen to follow the X.org behavior.
The /etc/motd file is edited upon every boot of the system, replacing everything up to, but not including, the first blank line with the system's kernel version information. When editing this file, make sure that you start after this blank line, to keep /etc/rc from deleting these lines when it edits /etc/motd upon boot.
See this document.
No it doesn't. We use a different mechanism to achieve similar results called Soft Updates. Please read FAQ 14 - Soft Updates to get more details.
Many new users to OpenBSD experience a two minute login delay when using services such as ssh or ftp. This can also be experienced when using a proxy, such as ftp-proxy, or when sending mail out from a workstation through sendmail.
This is almost always due to a reverse-DNS problem. DNS is Domain Name Services, 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 "Reverse DNS".
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, ftp, sendmail, or ftp-proxy. 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:
::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 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
|
In this case, I am assuming 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 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.
The present web pages have been carefully crafted to work on a wide variety of actual browsers going back to browser versions 4.0 and later. We do not want to make these older pages conform to HTML4 or XHTML until we're sure that they will also work with older browsers; it's just not a priority. We welcome new contributors, but suggest you work on writing code, or on documenting new aspects of the system, not on tweaking the existing web pages to conform to newer standards.
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 the UTC (Coordinated Universal Time, based on astronomical observations) time and TAI (International Atomic Time, based on atomic clocks) time. 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.
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
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
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:
# ln -fs /usr/share/zoneinfo/EST5EDT /etc/localtime
See also:
[FAQ Index] [To Section 7 - Keyboard and Display Controls] [To Section 9 - Migrating to OpenBSD]