LOGIN.CONF(5) File Formats Manual LOGIN.CONF(5)
login.conf - login class capability database
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) program, it is also used by other programs,
such as ftpd(8), 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.
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) must be run after each edit of /etc/login.conf to
keep the database version in sync with the plain file.
Refer to getcap(3) 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
Name Type Default Description
approve program Default program to approve
approve-service program Program to approve login for
auth list passwd Allowed authentication
styles. The first value is
the default styles.
auth-type list Allowed authentication styles
for the authentication type
classify program Classify type of login.
copyright file File containing additional
coredumpsize size Maximum coredump size limit.
cputime time CPU usage limit.
datasize size Maximum data size limit.
expire-warn time 2w If the user's account will
expire within this length of
time then warn the user of
filesize size Maximum file size limit.
hushlogin bool false Same as having a
$HOME/.hushlogin file. See
ignorenologin bool false Not affected by nologin
files. See login(1).
localcipher string blowfish,8 The cipher to use for
encrypting passwords. Refer
to crypt_newhash(3) for
login-backoff number 3 After login-backoff
unsuccessful login attempts
during a single session,
login(1) will start sleeping
a bit in between attempts.
login-timeout time 300 Number of seconds before
login(1) times out at the
password prompt. Note that
this setting is only valid
for the default record.
login-tries number 10 Number of tries a user gets
to successfully login before
login(1) closes the
stacksize size Maximum stack size limit.
maxproc number Maximum number of processes.
memorylocked size Maximum locked in core memory
memoryuse size Maximum in core memoryuse
minpasswordlen number 6 The minimum length a local
password may be. If a
negative value or zero, no
length restrictions are
enforced. Used by the
nologin file If the file exists it will be
displayed and the login
session will be terminated.
openfiles number Maximum number of open file
descriptors per process.
password-dead time 0 Length of time a password may
be expired but not quite dead
yet. When set (for both the
client and remote server
machine when doing remote
authentication), a user is
allowed to log in just one
more time after their
password (but not account)
has expired. This allows a
grace period for updating
password-warn time 2w If the user's password will
expire within this length of
time then warn the user of
passwordcheck program An external program that
checks the quality of the
password. The password is
passed to the program on
stdin. An exit code of 0
indicates that the quality of
the password is sufficient,
an exit code of 1 signals
that the password failed the
passwordtime time The lifetime of a password in
seconds, reset every time a
user changes their password.
When this value is exceeded
the user will no longer be
able to login unless the
password-dead option has been
specified. Used by the
passwordtries number 3 The number of times the
passwd(1) utility enforces a
check on the password. If 0,
the new password will only be
accepted if it passes the
password quality check.
path path value of _PATH_DEFPATH
Default search path. See
priority number Initial priority (nice)
requirehome bool false Require home directory to
setenv envlist A list of environment
variables and associated
values to be set for the
shell program Session shell to execute
rather than the shell
specified in the password
file. The SHELL environment
variable will contain the
shell specified in the
tc string Interpolate/expands records
login.conf. See getcap(3).
term string su Default terminal type if not
able to determine from other
umask number 022 Initial umask. Should always
have a leading 0 to ensure
octal interpretation. See
vmemoryuse size Maximum virtual memoryuse
welcome file /etc/motd File containing welcome
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)). 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
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. 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. 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. 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.
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).
crypto Authenticate using a CRYPTOCard token. See login_crypto(8).
lchpass Change user's local password. See login_lchpass(8).
passwd Request a password and check it against the password in the
master.passwd file. See login_passwd(8).
radius Normally linked to another authentication type, contact the
radius server to do authentication. See login_radius(8).
reject Request a password and reject any request. See
skey Send a challenge and request a response, checking it with
S/Key (tm) authentication. See login_skey(8).
snk Authenticate using a SecureNet Key token. See login_snk(8).
token Authenticate using a generic X9.9 token. See login_token(8).
yubikey Authenticate using a Yubico YubiKey token. See
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) 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) and radiusd(8). If no
service type is specified, login is used.
style The authentication style being used.
type The authentication type, used to determine the available
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) 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) will always
request the ftp type authentication, and su(1) will always request the su
type authentication. The login(1) 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)).
The class to be used is normally determined by the class field in the
password file (see passwd(5)).
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) 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) will place in the utmp file for the
local_addr The local IP address given to login(1) 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
login This is a new login session (as opposed to a simple
remote_addr The remote IP address given to login(1) by the -R option.
style The style of authentication used for this user (see
approval scripts below).
The su(1) 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) 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
authorize The user has been authorized.
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
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).
Authorization was rejected and a challenge has been made
available via the value challenge.
Authorization is rejected, but no error messages should be
If the login session fails for any reason, remove file before
setenv name value
If the login session succeeds, the environment variable name
should be set to the specified value.
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.
\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:
See section on challenges below.
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).
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.
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.
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.
A classify program has the synopsis of:
classify [-v name=value] [-f] [user]
See login(1) 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, 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) 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) 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
cap_mkdb(1), login(1), authenticate(3), bsd_auth(3), getcap(3),
login_cap(3), passwd(5), ttys(5), ftpd(8)
OpenBSD 5.9 October 1, 2015 OpenBSD 5.9
[Unix Hosting |
[Engineering & Automation |
Software Development |