---
name: "login.conf"
section: "5"
platform: "openbsd"
package: "man"
version: "8.0-current-20261101"
release: "OpenBSD 8.0-current (2026-11-01)"
platforms: ["freebsd", "openbsd"]
url: "https://new.carta.tech/login.conf"
---

# login.conf(5)

login class capability database

## NAME

**login.conf** – login class capability database

## DESCRIPTION

The **login.conf** file describes the various attributes of login classes. A login class determines what styles of authentication are available as well as session resource limits and environment setup. While designed primarily for the [login(1)](/login/1.md) program, it is also used by other programs, such as [ftpd(8)](/ftpd/8.md), to determine what means of authentication are available. It is also used by programs which need to set up a user environment.

A special record, “default”, in */etc/login.conf* is used for any user without a valid login class in */etc/master.passwd*.

In case the */etc/login.conf.d/${**class*} file exists, it will take precedence over the same login class defined in */etc/login.conf*.

Sites with very large */etc/login.conf* files may wish to create a database version of the file, */etc/login.conf.db*, for improved performance. Using a database version for small files does not result in a performance improvement. To build */etc/login.conf.db* from */etc/login.conf* the following command may be used:

```
# cap_mkdb /etc/login.conf
```

Note that [cap\_mkdb(1)](/cap_mkdb/1.md) must be run after each edit of */etc/login.conf* or the */etc/login.conf.d/${class}* file to keep the database version in sync with the plain file.

## CAPABILITIES

Refer to [cgetent(3)](/cgetent/3.md) for a description of the file layout. All entries in the **login.conf** file are either boolean or use a ‘=’ to separate the capability from the value. The types are described after the capability table.

| | | | |
| --- | --- | --- | --- |
| **Name** | **Type** | **Default** | **Description** |
| approve | program |  |  |
| approve-*service* | program |  |  |
| auth | list | passwd |  |
| auth-*type* | list |  |  |
| classify | program |  |  |
| copyright | file |  |  |
| coredumpsize | size |  |  |
| cputime | time |  |  |
| datasize | size |  |  |
| expire-warn | time | 2w |  |
| filesize | size |  |  |
| hushlogin | bool | false |  |
| ignorenologin | bool | false |  |
| localcipher | string | bcrypt,a |  |
| login-backoff | number | 3 |  |
| login-timeout | time | 300 |  |
| login-tries | number | 10 |  |
| stacksize | size |  |  |
| maxproc | number |  |  |
| memorylocked | size |  |  |
| memoryuse | size |  |  |
| minpasswordlen | number | 6 |  |
| nologin | file |  |  |
| openfiles | number |  |  |
| password-dead | time | 0 |  |
| password-warn | time | 2w |  |
| passwordcheck | program |  |  |
| passwordtime | time |  |  |
| passwordtries | number | 3 |  |
| path | path | value of \_PATH\_DEFPATH |  |
| priority | number |  |  |
| requirehome | bool | false |  |
| rtable | number |  |  |
| setenv | envlist |  |  |
| shell | program |  |  |
| tc | string |  |  |
| term | string | su |  |
| umask | number | 022 |  |
| vmemoryuse | size |  |  |
| welcome | file | */etc/motd* |  |

The resource limit entries (*cputime*, *filesize*, *datasize*, *stacksize*, *coredumpsize*, *memoryuse*, *memorylocked*, *maxproc*, and *openfiles*) actually specify both the maximum and current limits (see [getrlimit(2)](/getrlimit/2.md)). The current limit is the one normally used, although the user is permitted to increase the current limit to the maximum limit. The maximum and current limits may be specified individually by appending a *-max* or *-cur* to the capability name (e.g., *openfiles-max* and *openfiles-cur*).

OpenBSD will never define capabilities which start with x- or X-, these are reserved for external use (unless included through contributed software).

The argument types are defined as:

- envlist

  A comma-separated list of environment variables of the form variable=value. If no value is specified, the ‘=’ is optional. A ~ in the path name is expanded to the user's home directory if it is at the end of a string or is followed by a slash (‘/’) or the user's login name. A $ in the path name is expanded to the user's login name.

- file

  Path name to a text file.

- list

  A comma-separated list of values.

- number

  A number, or **infinity** for no limit. A leading 0x implies the number is expressed in hexadecimal. A leading 0 implies the number is expressed in octal. Any other number is treated as decimal.

- path

  A space-separated list of path names. Login name and directory are substituted as for *envlist*. Additionally, a ~ is only expanded at the beginning of a path name.

- program

  A path name to program.

- size

  A number which expresses a size, or **infinity** for no limit. By default, the size is specified in bytes. It may have a trailing b, k, m, g or t to indicate that the value is in 512-byte blocks, kilobytes, megabytes, gigabytes, or terabytes, respectively.

- time

  A time in seconds, or **infinity** for no limit. A time may be expressed as a series of numbers which are added together. Each number may have a trailing character to represent time units:

  - y

    Indicates a number of 365 day years.

  - w

    Indicates a number of 7 day weeks.

  - d

    Indicates a number of 24 hour days.

  - h

    Indicates a number of 60 minute hours.

  - m

    Indicates a number of 60 second minutes.

  - s

    Indicates a number of seconds.

    For example, to indicate 1 and 1/2 hours, the following string could be used: 1h30m.

## AUTHENTICATION

OpenBSD uses BSD Authentication, which is made up of a variety of authentication styles. The authentication styles currently provided are:

- activ

  Authenticate using an ActivCard token. See login\_activ(8).

- chpass

  Change user's password. See [login\_chpass(8)](/login_chpass/8.md).

- crypto

  Authenticate using a CRYPTOCard token. See login\_crypto(8).

- lchpass

  Change user's local password. See [login\_lchpass(8)](/login_lchpass/8.md).

- ldap

  Authenticate using an LDAP server. See [login\_ldap(8)](/login_ldap/8.md).

- passwd

  Request a password and check it against the password in the master.passwd file. See [login\_passwd(8)](/login_passwd/8.md).

- radius

  Normally linked to another authentication type, contact a RADIUS server to do authentication. See [login\_radius(8)](/login_radius/8.md).

- reject

  Request a password and reject any request. See [login\_reject(8)](/login_reject/8.md).

- skey

  Send a challenge and request a response, checking it with S/Key (tm) authentication. See [login\_skey(8)](/login_skey/8.md).

- snk

  Authenticate using a SecureNet Key token. See login\_snk(8).

- token

  Authenticate using a generic X9.9 token. See [login\_token(8)](/login_token/8.md).

- yubikey

  Authenticate using a Yubico YubiKey token. See [login\_yubikey(8)](/login_yubikey/8.md).

Local authentication styles may be added by creating a login script for the style (see below). To prevent collisions with future official BSD Authentication style names, all local style names should start with a dash (-). Current plans are for all official BSD Authentication style names to begin with a lower case alphabetic character. For example, if you have a new style you refer to as slick then you should create an authentication script named */usr/libexec/auth/login\_-slick* using the style name -slick. When logging in via the [login(1)](/login/1.md) program, the syntax *user*:-slick would be used.

Authentication requires several pieces of information:

- *class*

  The login class being used.

- *service*

  The type of service requesting authentication. The service type is used to determine what information the authentication program can provide to the user and what information the user can provide to the authentication program.

  The service type login is appropriate for most situations. Two other service types, challenge and response, are provided for use by programs like [ftpd(8)](/ftpd/8.md) and [radiusd(8)](/radiusd/8.md). If no service type is specified, login is used.

- *style*

  The authentication style being used.

- *type*

  The authentication type, used to determine the available authentication styles.

- *username*

  The name of the user to authenticate. The name may contain an instance. If the authentication style being used does not support such instances, the request will fail.

The program requesting authentication must specify a username and an authentication style. (For example, [login(1)](/login/1.md) requests a username from the user. Users may enter usernames of the form “user:style” to optionally specify the authentication style.) The requesting program may also specify the type of authentication that will be done. Most programs will only have a single type, if any at all, i.e., [ftpd(8)](/ftpd/8.md) will always request the ftp type authentication, and [su(1)](/su/1.md) will always request the su type authentication. The [login(1)](/login/1.md) utility is special in that it may select an authentication type based on information found in the */etc/ttys* file for the appropriate tty (see [ttys(5)](/ttys/5.md)).

The class to be used is normally determined by the class field in the password file (see [passwd(5)](/passwd/5.md)).

The class is used to look up a corresponding entry in the *login.conf* file. If an authentication type is defined and a value for auth-*type* exists in that entry, it will be used as a list of potential authentication styles. If an authentication type is not defined, or auth-*type* is not specified for the class, the value of auth is used as the list of available authentication styles.

If the user did not specify an authentication style, the first style in the list of available styles is used. If the user did specify an authentication style and the style is in the list of available styles it will be used, otherwise the request is rejected.

For any given style, the program */usr/libexec/auth/login\_**style* is used to perform the authentication. The synopsis of this program is:

/usr/libexec/auth/login\_*style* \[**-v** *name=value*\] \[**-s** *service*\] *username* *class*

The **-v** option is used to specify arbitrary information to the authentication programs. Any number of **-v** options may be used. The [login(1)](/login/1.md) program provides the following through the **-v** option:

- auth\_type

  The type of authentication to use.

- fqdn

  The hostname provided to login by the **-h** option.

- hostname

  The name [login(1)](/login/1.md) will place in the utmp file for the remote hostname.

- local\_addr

  The local IP address given to [login(1)](/login/1.md) by the **-L** option.

- lastchance

  Set to “yes” when a user's password has expired but the user is being given one last chance to login and update the password.

- login

  This is a new login session (as opposed to a simple identity check).

- remote\_addr

  The remote IP address given to [login(1)](/login/1.md) by the **-R** option.

- style

  The style of authentication used for this user (see approval scripts below).

The [su(1)](/su/1.md) program provides the following through the **-v** option:

- wheel

  Set to either “yes” or “no” to indicate if the user is in group wheel when they are trying to become root. Some authentication types require the user to be in group wheel when using the [su(1)](/su/1.md) program to become super user.

When the authentication program is executed, the environment will only contain the values PATH=/bin:/usr/bin and SHELL=/bin/sh. File descriptor 3 will be open for reading and writing. The authentication program should write one or more of the following strings to this file descriptor:

- authorize

  The user has been authorized.

- authorize secure

  The user has been authorized and root should be allowed to login even if this is not a secure terminal. This should only be sent by authentication styles that are secure over insecure lines.

- reject

  Authorization is rejected. This overrides any indication that the user was authorized (though one would question the wisdom in sending both a *reject* and an *authorize* command).

- reject challenge

  Authorization was rejected and a challenge has been made available via the value challenge.

- reject silent

  Authorization is rejected, but no error messages should be generated.

- remove *file*

  If the login session fails for any reason, remove *file* before termination.

- setenv *name* *value*

  If the login session succeeds, the environment variable *name* should be set to the specified *value*.

- unsetenv *name*

  If the login session succeeds, the environment variable *name* should be removed.

- value *name* *value*

  Set the internal variable *name* to the specified *value*. The *value* should only contain printable characters. Several \\ sequences may be used to introduce non printing characters. These are:

  - \\n

    A newline.

  - \\r

    A carriage return.

  - \\t

    A tab.

  - \\*xxx*

    The character represented by the octal value *xxx*. The value may be one, two, or three octal digits.

  - \\*c*

    The string is replaced by the value of *c*. This allows quoting an initial space or the \\ character itself.

    The following values are currently defined:

    - challenge

      See section on challenges below.

    - errormsg

      If set, the value is the reason authentication failed. The calling program may choose to display this when rejecting the user, but display is not required.

In order for authentication to be successful, the authentication program must exit with a value of 0 as well as provide an authorize or authorize root statement on file descriptor 3.

An authentication program must not assume it will be called as root, nor must it assume it will not be called as root. If it needs special permissions to access files, it should be setuid or setgid to the appropriate user/group. See [chmod(1)](/chmod/1.md).

## CHALLENGES

When an authentication program is called with a service of challenge it should do one of three things:

If this style of authentication supports challenge response, it should set the internal variable challenge to be the appropriate challenge for the user. This is done by the value command listed above. The program should also issue a reject challenge and then exit with a 0 status. See the section on responses below.

If this style of authentication does not support challenge response, but does support the response service (described below) it should issue reject silent and then exit with a 0 status.

If this style of authentication does not support the response service it should simply fail, complaining about an unknown service type. It should exit with a non-zero status.

## RESPONSES

When an authentication program is called with a service of response, and this style supports this mode of authentication, it should read two null terminated strings from file descriptor 3. The first string is a challenge that was issued to the user (obtained from the challenge service above). The second string is the response the user gave (i.e., the password). If the response is correct for the specified challenge, the authentication should be accepted, else it should be rejected. It is possible for the challenge to be an empty string, which implies the calling program did first obtain a challenge prior to getting a response from the user. Not all authentication styles support empty challenges.

## APPROVAL

An approval program has the synopsis of:

*approve* \[**-v** *name=value*\] *username* *class* *service*

Just as with an authentication program, file descriptor 3 will be open for writing when the approval program is executed. The **-v** option is the same as in the authentication program. Unlike an authentication program, the approval program need not explicitly send an authorize or authorize root statement, it only need exit with a value of 0 or non-zero. An exit value of 0 is equivalent to an authorize statement, and non-zero to a reject statement. This allows for simple programs which have no information to provide other than approval or denial.

## CLASSIFICATION

A classify program has the synopsis of:

*classify* \[**-v** *name=value*\] \[**-f**\] \[user\]

See [login(1)](/login/1.md) for a description of the **-f**, option. The **-v** option is the same as for the authentication programs. The *user* is the username passed to [login(1)](/login/1.md) login, if any.

The typical job of the classify program is to determine what authentication type should actually be used, presumably based on the remote IP address. It might also re-specify the hostname to be included in the [utmp(5)](/utmp/5.md) file, reject the login attempt outright, or even print an additional login banner (e.g., */etc/issue*).

The classify entry is only valid for the default class as it is used prior to knowing who the user is. The classify script may pass environment variables or other commands back to [login(1)](/login/1.md) on file descriptor 3, just as an authentication program does. The two variables **AUTH\_TYPE** and **REMOTE\_NAME** are used to specify a new authentication type (the type must have the form auth-*type*) and override the **-h** option to login, respectively.

## FILES

- */etc/login.conf*

  Login class capability database.

- */etc/login.conf.d/${**class*}

  Login class capability database for the specified login class.

## SEE ALSO

[cap\_mkdb(1)](/cap_mkdb/1.md), [login(1)](/login/1.md), auth\_subr(3), authenticate(3), [cgetent(3)](/cgetent/3.md), [login\_cap(3)](/login_cap/3.md), [passwd(5)](/passwd/5.md), [ttys(5)](/ttys/5.md), [ftpd(8)](/ftpd/8.md)