1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
|
'\" te
.\" Copyright (c) 1997, Sun Microsystems, Inc. All Rights Reserved
.\" Copyright 1989 AT&T
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH HOSTS.EQUIV 4 "Nov 26, 2017"
.SH NAME
hosts.equiv, rhosts \- trusted remote hosts and users
.SH DESCRIPTION
.LP
The \fB/etc/hosts.equiv\fR and \fB\&.rhosts\fR files provide the "remote
authentication" database for \fBrlogin\fR(1), \fBrsh\fR(1), \fBrcp\fR(1), and
\fBrcmd\fR(3SOCKET). The files specify remote hosts and users that are
considered "trusted". Trusted users are allowed to access the local system
without supplying a password. The library routine \fBruserok()\fR (see
\fBrcmd\fR(3SOCKET)) performs the authentication procedure for programs by
using the \fB/etc/hosts.equiv\fR and \fB\&.rhosts\fR files. The
\fB/etc/hosts.equiv\fR file applies to the entire system, while individual
users can maintain their own \fB\&.rhosts\fR files in their home directories.
.sp
.LP
These files bypass the standard password-based user authentication mechanism.
To maintain system security, care must be taken in creating and maintaining
these files.
.sp
.LP
The remote authentication procedure determines whether a user from a remote
host should be allowed to access the local system with the identity of a local
user. This procedure first checks the \fB/etc/hosts.equiv\fR file and then
checks the \fB\&.rhosts\fR file in the home directory of the local user who is
requesting access. Entries in these files can be of two forms. Positive entries
allow access, while negative entries deny access. The authentication succeeds
when a matching positive entry is found. The procedure fails when the first
matching negative entry is found, or if no matching entries are found in either
file. The order of entries is important. If the files contain both positive and
negative entries, the entry that appears first will prevail. The \fBrsh\fR(1)
and \fBrcp\fR(1) programs fail if the remote authentication procedure fails.
The \fBrlogin\fR program falls back to the standard password-based login
procedure if the remote authentication fails.
.sp
.LP
Both files are formatted as a list of one-line entries. Each entry has the
form:
.sp
.in +2
.nf
\fIhostname\fR [\fIusername\fR]
.fi
.in -2
.sp
.sp
.LP
Hostnames must be the official name of the host, not one of its nicknames.
.sp
.LP
Negative entries are differentiated from positive entries by a `\(mi' character
preceding either the \fIhostname\fR or \fIusername\fR field.
.SS "Positive Entries"
.LP
If the form:
.sp
.in +2
.nf
\fIhostname\fR
.fi
.in -2
.sp
.sp
.LP
is used, then users from the named host are trusted. That is, they may access
the system with the same user name as they have on the remote system. This form
may be used in both the \fB/etc/hosts.equiv\fR and \fB\&.rhosts\fR files.
.sp
.LP
If the line is in the form:
.sp
.in +2
.nf
\fIhostname\fR \fIusername\fR
.fi
.in -2
.sp
.sp
.LP
then the named user from the named host can access the system. This form may be
used in individual \fB\&.rhosts\fR files to allow remote users to access the
system \fIas a different local user\fR. If this form is used in the
\fB/etc/hosts.equiv\fR file, the named remote user will be allowed to access
the system as \fBany\fR local user.
.sp
.LP
\fBnetgroup\fR(4) can be used in either the \fIhostname\fR or \fIusername\fR
fields to match a number of hosts or users in one entry. The form:
.sp
.in +2
.nf
\fB+@\fR\fInetgroup\fR
.fi
.in -2
.sp
.sp
.LP
allows access from all hosts in the named netgroup. When used in the
\fIusername\fR field, netgroups allow a group of remote users to access the
system as a particular local user. The form:
.sp
.in +2
.nf
\fIhostname\fR \fB+@\fR\fInetgroup\fR
.fi
.in -2
.sp
.sp
.LP
allows all of the users in the named netgroup from the named host to access the
system as the local user. The form:
.sp
.in +2
.nf
\fB+@\fR\fInetgroup1\fR \fB+@\fR\fInetgroup2\fR
.fi
.in -2
.sp
.sp
.LP
allows the users in \fInetgroup2\fR from the hosts in \fInetgroup1\fR to access
the system as the local user.
.sp
.LP
The special character `+' can be used in place of either \fIhostname\fR or
\fIusername\fR to match any host or user. For example, the entry
.sp
.in +2
.nf
\fB+\fR
.fi
.in -2
.sp
.sp
.LP
will allow a user from any remote host to access the system with the same
username. The entry
.sp
.in +2
.nf
\fB+\fR \fIusername\fR
.fi
.in -2
.sp
.sp
.LP
will allow the named user from any remote host to access the system. The entry
.sp
.in +2
.nf
\fIhostname\fR \fB+\fR
.fi
.in -2
.sp
.sp
.LP
will allow any user from the named host to access the system as the local user.
.SS "Negative Entries"
.LP
Negative entries are preceded by a `\(mi' sign. The form:
.sp
.in +2
.nf
\fB\(mi\fR\fIhostname\fR
.fi
.in -2
.sp
.sp
.LP
will disallow all access from the named host. The form:
.sp
.in +2
.nf
\fB\(mi@\fR\fInetgroup\fR
.fi
.in -2
.sp
.sp
.LP
means that access is explicitly disallowed from all hosts in the named
netgroup. The form:
.sp
.in +2
.nf
\fIhostname\fR \fB\(mi\fR\fIusername\fR
.fi
.in -2
.sp
.sp
.LP
disallows access by the named user only from the named host, while the form:
.sp
.in +2
.nf
\fB+ \(mi@\fR\fInetgroup\fR
.fi
.in -2
.sp
.sp
.LP
will disallow access by all of the users in the named netgroup from all hosts.
.SS "Search Sequence"
.LP
To help maintain system security, the \fB/etc/hosts.equiv\fR file is not
checked when access is being attempted for super-user. If the user attempting
access is not the super-user, \fB/etc/hosts.equiv\fR is searched for lines of
the form described above. Checks are made for lines in this file in the
following order:
.RS +4
.TP
1.
\fB+\fR
.RE
.RS +4
.TP
2.
\fB+@\fR\fInetgroup\fR
.RE
.RS +4
.TP
3.
\fB\(mi@\fR\fInetgroup\fR
.RE
.RS +4
.TP
4.
\fB\(mi\fR\fIhostname\fR
.RE
.RS +4
.TP
5.
\fIhostname\fR
.RE
.sp
.LP
The user is granted access if a positive match occurs. Negative entries apply
only to \fB/etc/hosts.equiv\fR and may be overridden by subsequent
\fB\&.rhosts\fR entries.
.sp
.LP
If no positive match occurred, the \fB\&.rhosts\fR file is then searched if the
user attempting access maintains such a file. This file is searched whether or
not the user attempting access is the super-user. As a security feature, the
\fB\&.rhosts\fR file must be owned by the user who is attempting access. Checks
are made for lines in \fB\&.rhosts\fR in the following order:
.RS +4
.TP
1.
\fB+\fR
.RE
.RS +4
.TP
2.
\fB+@\fR\fInetgroup\fR
.RE
.RS +4
.TP
3.
\fB\(mi@\fR\fInetgroup\fR
.RE
.RS +4
.TP
4.
\fB\(mi\fR\fIhostname\fR
.RE
.RS +4
.TP
5.
\fIhostname\fR
.RE
.SH FILES
.ne 2
.na
\fB\fB/etc/hosts.equiv\fR\fR
.ad
.RS 20n
system trusted hosts and users
.RE
.sp
.ne 2
.na
\fB\fB~/.rhosts\fR\fR
.ad
.RS 20n
user's trusted hosts and users
.RE
.SH SEE ALSO
.LP
\fBrcp\fR(1), \fBrlogin\fR(1), \fBrsh\fR(1), \fBrcmd\fR(3SOCKET),
\fBhosts\fR(4), \fBnetgroup\fR(4), \fBpasswd\fR(4)
.SH WARNINGS
.LP
Positive entries in \fB/etc/hosts.equiv\fR that include a \fIusername\fR field
(either an individual named user, a netgroup, or `\fB+\fR' sign) should be
used with extreme caution. Because \fB/etc/hosts.equiv\fR applies system-wide,
these entries allow one, or a group of, remote users to access the system
\fBas any local user\fR. This can be a security hole. For example, because of
the search sequence, an \fB/etc/hosts.equiv\fR file consisting of the entries
.sp
.in +2
.nf
\fB+
\(mihostxxx\fR
.fi
.in -2
.sp
.sp
.LP
will not deny access to "hostxxx".
|