Merge branch 'vendor/MDOCML'
[dragonfly.git] / contrib / opie / opieaccess.5
CommitLineData
984263bc
MD
1.\" opieaccess.5: Manual page describing the /etc/opieaccess file.
2.\"
3.\" Portions of this software are Copyright 1995 by Randall Atkinson and Dan
4.\" McDonald, All Rights Reserved. All Rights under this copyright are assigned
5.\" to the U.S. Naval Research Laboratory (NRL). The NRL Copyright Notice and
6.\" License Agreement applies to this software.
7.\"
8.\" History:
9.\"
10.\" Modified by cmetz for OPIE 2.4. Fixed "0PIE" typo.
11.\" Written at NRL for OPIE 2.0.
12.\"
13.ll 6i
14.pl 10.5i
15.\" @(#)opieaccess.5 2.0 (NRL) 1/10/95
16.\" $FreeBSD: src/contrib/opie/opieaccess.5,v 1.2.8.3 2002/07/15 14:48:43 des Exp $
1de703da 17.\" $DragonFly: src/contrib/opie/opieaccess.5,v 1.2 2003/06/17 04:24:05 dillon Exp $
984263bc
MD
18.\"
19.lt 6.0i
20.TH OPIEACCESS 5 "January 10, 1995"
21.AT 3
22.SH NAME
23/etc/opieaccess \- OPIE database of trusted networks
24
25.SH DESCRIPTION
26The
27.I opieaccess
28file contains a list of networks that are considered trusted by the system as
29far as security against passive attacks is concerned. Users from networks so
30trusted will be able to log in using OPIE responses, but not be required to
31do so, while users from networks that are not trusted will always be required
32to use OPIE responses (the default behavior). This trust allows a site to
33have a more gentle migration to OPIE by allowing it to be non-mandatory for
34"inside" networks while allowing users to choose whether they with to use OPIE
35to protect their passwords or not.
36.sp
37The entire notion of trust implemented in the
38.I opieaccess
39file is a major security hole because it opens your system back up to the same
40passive attacks that the OPIE system is designed to protect you against. The
41.I opieaccess
42support in this version of OPIE exists solely because we believe that it is
43better to have it so that users who don't want their accounts broken into can
44use OPIE than to have them prevented from doing so by users who don't want
45to use OPIE. In any environment, it should be considered a transition tool and
46not a permanent fixture. When it is not being used as a transition tool, a
47version of OPIE that has been built without support for the
48.I opieaccess
49file should be built to prevent the possibility of an attacker using this file
50as a means to circumvent the OPIE software.
51.sp
52The
53.I opieaccess
54file consists of lines containing three fields separated by spaces (tabs are
55properly interpreted, but spaces should be used instead) as follows:
56.PP
57.nf
58.ta \w' 'u
59Field Description
60action "permit" or "deny" non-OPIE logins
61address Address of the network to match
62mask Mask of the network to match
63.fi
64
65Subnets can be controlled by using the appropriate address and mask. Individual
66hosts can be controlled by using the appropriate address and a mask of
67255.255.255.255. If no rules are matched, the default is to deny non-OPIE
68logins.
69
70.SH SEE ALSO
71.BR ftpd (8)
72.BR login (1),
73.BR opie (4),
74.BR opiekeys (5),
75.BR opiepasswd (1),
76.BR opieinfo (1),
77.BR su (1),
78
79.SH AUTHOR
80Bellcore's S/Key was written by Phil Karn, Neil M. Haller, and John S. Walden
81of Bellcore. OPIE was created at NRL by Randall Atkinson, Dan McDonald, and
82Craig Metz.
83
84S/Key is a trademark of Bell Communications Research (Bellcore).
85
86.SH CONTACT
87OPIE is discussed on the Bellcore "S/Key Users" mailing list. To join,
88send an email request to:
89.sp
90skey-users-request@thumper.bellcore.com