Print this page
14249 pseudo-terminal nomenclature should reflect POSIX
Change-Id: Ib4a3cef899ff4c71b09cb0dc6878863c5e8357bc
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/man/man1m/in.telnetd.1m.man.txt
+++ new/usr/src/man/man1m/in.telnetd.1m.man.txt
1 1 IN.TELNETD(1M) Maintenance Commands IN.TELNETD(1M)
2 2
3 3 NAME
4 4 in.telnetd, telnetd - DARPA TELNET protocol server
5 5
6 6 SYNOPSIS
7 7 /usr/sbin/in.telnetd [-a authmode] [-EXUh] [-s tos]
8 8 [-S keytab] [-M realm]
|
↓ open down ↓ |
8 lines elided |
↑ open up ↑ |
9 9
10 10
11 11 DESCRIPTION
12 12 in.telnetd is a server that supports the DARPA standard TELNET virtual
13 13 terminal protocol. in.telnetd is normally invoked in the internet
14 14 server (see inetd(1M)), for requests to connect to the TELNET port as
15 15 indicated by the /etc/services file (see services(4)).
16 16
17 17
18 18 in.telnetd operates by allocating a pseudo-terminal device for a
19 - client, then creating a login process which has the slave side of the
20 - pseudo-terminal as its standard input, output, and error. in.telnetd
21 - manipulates the master side of the pseudo-terminal, implementing the
22 - TELNET protocol and passing characters between the remote client and
23 - the login process.
19 + client, then creating a login process which has the subsidiary side of
20 + the pseudo-terminal as its standard input, output, and error.
21 + in.telnetd manipulates the manager side of the pseudo-terminal,
22 + implementing the TELNET protocol and passing characters between the
23 + remote client and the login process.
24 24
25 25
26 26 When a TELNET session starts up, in.telnetd sends TELNET options to the
27 27 client side indicating a willingness to do remote echo of characters,
28 28 and to suppress go ahead. The pseudo-terminal allocated to the client
29 29 is configured to operate in "cooked" mode, and with XTABS, ICRNL and
30 30 ONLCR enabled. See termio(7I).
31 31
32 32
33 33 in.telnetd is willing to do: echo, binary, suppress go ahead, and
34 34 timing mark. in.telnetd is willing to have the remote client do:
35 35 binary, terminal type, terminal size, logout option, and suppress go
36 36 ahead.
37 37
38 38
39 39 in.telnetd also allows environment variables to be passed, provided
40 40 that the client negotiates this during the initial option negotiation.
41 41 The DISPLAY environment variable may be sent this way, either by the
42 42 TELNET general environment passing methods, or by means of the XDISPLOC
43 43 TELNET option. DISPLAY can be passed in the environment option during
44 44 the same negotiation where XDISPLOC is used. Note that if you use both
45 45 methods, use the same value for both. Otherwise, the results may be
46 46 unpredictable.
47 47
48 48
49 49 These options are specified in Internet standards RFC 1096, RFC 1408,
50 50 RFC 1510, RFC 1571, RFC 2941, RFC 2942, RFC 2946, and RFC 1572. The
51 51 following Informational draft is also supported: RFC 2952.
52 52
53 53
54 54 The banner printed by in.telnetd is configurable. The default is (more
55 55 or less) equivalent to `uname -sr` and will be used if no banner is set
56 56 in /etc/default/telnetd. To set the banner, add a line of the form
57 57
58 58 BANNER="..."
59 59
60 60
61 61
62 62 to /etc/default/telnetd. Nonempty banner strings are fed to shells for
63 63 evaluation. The default banner may be obtained by
64 64
65 65 BANNER="\\r\\n\\r\\n`uname -s` `uname -r`\\r\\n\\r\\n"
66 66
67 67
68 68
69 69 and no banner will be printed if /etc/default/telnetd contains
70 70
71 71 BANNER=""
72 72
73 73
74 74 OPTIONS
75 75 The following options are supported:
76 76
77 77 -a authmode
78 78 This option may be used for specifying what mode should
79 79 be used for authentication. There are several valid
80 80 values for authmode:
81 81
82 82 valid
83 83 Only allows connections when the remote user
84 84 can provide valid authentication information to
85 85 identify the remote user, and is allowed access
86 86 to the specified account without providing a
87 87 password.
88 88
89 89
90 90 user
91 91 Only allows connections when the remote user
92 92 can provide valid authentication information to
93 93 identify the remote user. The login(1) command
94 94 will provide any additional user verification
95 95 needed if the remote user is not allowed
96 96 automatic access to the specified account.
97 97
98 98
99 99 none
100 100 This is the default state. Authentication
101 101 information is not required. If no or
102 102 insufficient authentication information is
103 103 provided, then the login(1) program provides
104 104 the necessary user verification.
105 105
106 106
107 107 off
108 108 This disables the authentication code. All user
109 109 verification happens through the login(1)
110 110 program.
111 111
112 112
113 113
114 114 -E
115 115 Disables encryption support negotiation.
116 116
117 117
118 118 -h
119 119 Disables displaying host specific information before
120 120 login has been completed.
121 121
122 122
123 123 -M realm
124 124 Uses the indicated Kerberos V5 realm. By default, the
125 125 daemon will determine its realm from the settings in the
126 126 krb5.conf(4) file.
127 127
128 128
129 129 -s tos
130 130 Sets the IP TOS option.
131 131
132 132
133 133 -S keytab
134 134 Sets the KRB5 keytab file to use. The
135 135 /etc/krb5/krb5.keytab file is used by default.
136 136
137 137
138 138 -U
139 139 Refuses connections that cannot be mapped to a name
140 140 through the getnameinfo(3SOCKET) function.
141 141
142 142
143 143 -X
144 144 Disables Kerberos V5 authentication support negotiation.
145 145
146 146
147 147 USAGE
148 148 telnetd and in.telnetd are IPv6-enabled. See ip6(7P).
149 149
150 150 SECURITY
151 151 in.telnetd can authenticate using Kerberos V5 authentication,
152 152 pam(3PAM), or both. By default, the telnet server will accept valid
153 153 Kerberos V5 authentication credentials from a telnet client that
154 154 supports Kerberos. in.telnetd can also support an encrypted session
155 155 from such a client if the client requests it.
156 156
157 157
158 158 The telnet protocol only uses single DES for session
159 159 protection--clients request service tickets with single DES session
160 160 keys. The KDC must know that host service principals that offer the
161 161 telnet service support single DES, which, in practice, means that such
162 162 principals must have single DES keys in the KDC database.
163 163
164 164
165 165 In order for Kerberos authentication to work, a host/<FQDN> Kerberos
166 166 principal must exist for each Fully Qualified Domain Name associated
167 167 with the telnetd server. Each of these host/<FQDN> principals must have
168 168 a keytab entry in the /etc/krb5/krb5.keytab file on the telnetd server.
169 169 An example principal might be:
170 170
171 171
172 172 host/bigmachine.eng.example.com
173 173
174 174
175 175 See kadmin(1M) for instructions on adding a principal to a krb5.keytab
176 176 file. See for a discussion of Kerberos authentication.
177 177
178 178
179 179 in.telnetd uses pam(3PAM) for authentication, account management,
180 180 session management, and password management. The PAM configuration
181 181 policy, listed through /etc/pam.conf, specifies the modules to be used
182 182 for in.telnetd. Here is a partial pam.conf file with entries for the
183 183 telnet command using the UNIX authentication, account management,
184 184 session management, and password management modules.
185 185
186 186 telnet auth requisite pam_authtok_get.so.1
187 187 telnet auth required pam_dhkeys.so.1
188 188 telnet auth required pam_unix_auth.so.1
189 189
190 190 telnet account requisite pam_roles.so.1
191 191 telnet account required pam_projects.so.1
192 192 telnet account required pam_unix_account.so.1
193 193
194 194 telnet session required pam_unix_session.so.1
195 195
196 196 telnet password required pam_dhkeys.so.1
197 197 telnet password requisite pam_authtok_get.so.1
198 198 telnet password requisite pam_authtok_check.so.1
199 199 telnet password required pam_authtok_store.so.1
200 200
201 201
202 202
203 203 If there are no entries for the telnet service, then the entries for
204 204 the "other" service will be used. If multiple authentication modules
205 205 are listed, then the user may be prompted for multiple passwords.
206 206
207 207
208 208 For a Kerberized telnet service, the correct PAM service name is
209 209 ktelnet.
210 210
211 211 FILES
212 212 /etc/default/telnetd
213 213
214 214
215 215
216 216 SEE ALSO
217 217 login(1), svcs(1), telnet(1), inetadm(1M), inetd(1M), kadmin(1M),
218 218 svcadm(1M), pam(3PAM), getnameinfo(3SOCKET), issue(4), krb5.conf(4),
219 219 pam.conf(4), services(4), attributes(5), pam_authtok_check(5),
220 220 pam_authtok_get(5), pam_authtok_store(5), pam_dhkeys(5),
221 221 pam_passwd_auth(5), pam_unix_account(5), pam_unix_auth(5),
222 222 pam_unix_session(5), smf(5), ip6(7P), termio(7I)
223 223
224 224
225 225
226 226
227 227 Alexander, S. RFC 1572, TELNET Environment Option. Network Information
228 228 Center, SRI International, Menlo Park, Calif., January 1994.
229 229
230 230
231 231 Borman, Dave. RFC 1408, TELNET Environment Option. Network Information
232 232 Center, SRI International, Menlo Park, Calif., January 1993.
233 233
234 234
235 235 Borman, Dave. RFC 1571, TELNET Environment Option Interoperability
236 236 Issues. Network Information Center, SRI International, Menlo Park,
237 237 Calif., January 1994.
238 238
239 239
240 240 Crispin, Mark. RFC 727, TELNET Logout Option. Network Information
241 241 Center, SRI International, Menlo Park, Calif., April 1977.
242 242
243 243
244 244 Marcy, G. RFC 1096, TELNET X Display Location Option. Network
245 245 Information Center, SRI International, Menlo Park, Calif., March 1989.
246 246
247 247
248 248 Postel, Jon, and Joyce Reynolds. RFC 854, TELNET Protocol
249 249 Specification. Network Information Center, SRI International, Menlo
250 250 Park, Calif., May 1983.
251 251
252 252
253 253 Waitzman, D. RFC 1073, TELNET Window Size Option. Network Information
254 254 Center, SRI International, Menlo Park, Calif., October 1988.
255 255
256 256
257 257 Kohl, J., Neuman, C., The Kerberos Network Authentication Service (V5),
258 258 RFC 1510. September 1993.
259 259
260 260
261 261 Ts'o, T. and J. Altman, Telnet Authentication Option, RFC 2941.
262 262 September 2000.
263 263
264 264
265 265 Ts'o, T., Telnet Authentication: Kerberos Version 5, RFC 2942.
266 266 September 2000.
267 267
268 268
269 269 Ts'o, T., Telnet Data Encryption Option, RFC 2946. September 2000.
270 270
271 271
272 272 Ts'o, T., Telnet Encryption: DES 64 bit Cipher Feedback, RFC 2952.
273 273 September 2000.
274 274
275 275 NOTES
276 276 Some TELNET commands are only partially implemented.
277 277
278 278
279 279 Binary mode has no common interpretation except between similar
280 280 operating systems.
281 281
282 282
283 283 The terminal type name received from the remote client is converted to
284 284 lower case.
285 285
286 286
287 287 The packet interface to the pseudo-terminal should be used for more
288 288 intelligent flushing of input and output queues.
289 289
290 290
291 291 in.telnetd never sends TELNET go ahead commands.
292 292
293 293
294 294 The pam_unix(5) module is no longer supported.. Similar functionality
295 295 is provided by pam_authtok_check(5), pam_authtok_get(5),
296 296 pam_authtok_store(5), pam_dhkeys(5), pam_passwd_auth(5),
297 297 pam_unix_account(5), pam_unix_auth(5), and pam_unix_session(5).
298 298
299 299
300 300 The in.telnetd service is managed by the service management facility,
301 301 smf(5), under the service identifier:
302 302
303 303 svc:/network/telnet
304 304
|
↓ open down ↓ |
271 lines elided |
↑ open up ↑ |
305 305
306 306
307 307
308 308 Administrative actions on this service, such as enabling, disabling, or
309 309 requesting restart, can be performed using svcadm(1M). Responsibility
310 310 for initiating and restarting this service is delegated to inetd(1M).
311 311 Use inetadm(1M) to make configuration changes and to view configuration
312 312 information for this service. The service's status can be queried using
313 313 the svcs(1) command.
314 314
315 - June 20, 2021 IN.TELNETD(1M)
315 + February 5, 2022 IN.TELNETD(1M)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX