1in.telnetd(1M)          System Administration Commands          in.telnetd(1M)
2
3
4

NAME

6       in.telnetd, telnetd - DARPA TELNET protocol server
7

SYNOPSIS

9       /usr/sbin/in.telnetd [-a authmode] [-EXUh] [-s tos]
10            [-S keytab] [-M realm]
11
12

DESCRIPTION

14       in.telnetd  is a server that supports the DARPA standard TELNET virtual
15       terminal protocol. in.telnetd  is  normally  invoked  in  the  internet
16       server  (see  inetd(1M)), for requests to connect to the TELNET port as
17       indicated by the /etc/services file (see services(4)).
18
19
20       in.telnetd operates  by  allocating  a  pseudo-terminal  device  for  a
21       client,  then  creating a login process which has the slave side of the
22       pseudo-terminal as its standard input, output,  and  error.  in.telnetd
23       manipulates  the  master  side of the pseudo-terminal, implementing the
24       TELNET protocol and passing characters between the  remote  client  and
25       the login process.
26
27
28       When a TELNET session starts up, in.telnetd sends TELNET options to the
29       client side indicating a willingness to do remote echo  of  characters,
30       and  to  suppress go ahead. The pseudo-terminal allocated to the client
31       is configured to operate in "cooked" mode, and with  XTABS,  ICRNL  and
32       ONLCR enabled. See termio(7I).
33
34
35       in.telnetd  is willing to do: echo, binary, suppress go ahead, and tim‐
36       ing mark. in.telnetd is willing to have the remote client  do:  binary,
37       terminal type, terminal size, logout option, and suppress go ahead.
38
39
40       in.telnetd  also  allows  environment  variables to be passed, provided
41       that the client negotiates this during the initial option  negotiation.
42       The  DISPLAY  environment  variable may be sent this way, either by the
43       TELNET general environment passing methods, or by means of the XDISPLOC
44       TELNET  option.  DISPLAY can be passed in the environment option during
45       the same negotiation where XDISPLOC is used. Note that if you use  both
46       methods,  use  the  same  value for both. Otherwise, the results may be
47       unpredictable.
48
49
50       These options are specified in Internet standards RFC 1096,  RFC  1408,
51       RFC  1510,  RFC  1571,  RFC 2941, RFC 2942, RFC 2946, and RFC 1572. The
52       following Informational draft is also supported: RFC 2952.
53
54
55       The banner printed by in.telnetd is configurable. The default is  (more
56       or less) equivalent to `uname -sr` and will be used if no banner is set
57       in /etc/default/telnetd. To set the banner, add a line of the form
58
59         BANNER="..."
60
61
62
63       to /etc/default/telnetd. Nonempty banner strings are fed to shells  for
64       evaluation. The default banner may be obtained by
65
66         BANNER="\\r\\n\\r\\n`uname -s` `uname -r`\\r\\n\\r\\n"
67
68
69
70       and no banner will be printed if /etc/default/telnetd contains
71
72         BANNER=""
73
74

OPTIONS

76       The following options are supported:
77
78       -a authmode    This  option may be used for specifying what mode should
79                      be used for authentication. There are several valid val‐
80                      ues for authmode:
81
82                      valid    Only  allows  connections  when the remote user
83                               can provide valid authentication information to
84                               identify the remote user, and is allowed access
85                               to the specified account  without  providing  a
86                               password.
87
88
89                      user     Only  allows  connections  when the remote user
90                               can provide valid authentication information to
91                               identify  the remote user. The login(1) command
92                               will provide any additional  user  verification
93                               needed  if the remote user is not allowed auto‐
94                               matic access to the specified account.
95
96
97                      none     This  is  the  default  state.   Authentication
98                               information  is not required. If no or insuffi‐
99                               cient authentication information  is  provided,
100                               then  the  login(1) program provides the neces‐
101                               sary user verification.
102
103
104                      off      This disables the authentication code. All user
105                               verification  happens through the login(1) pro‐
106                               gram.
107
108
109
110       -E             Disables encryption support negotiation.
111
112
113       -h             Disables displaying  host  specific  information  before
114                      login has been completed.
115
116
117       -M realm       Uses  the  indicated  Kerberos V5 realm. By default, the
118                      daemon will determine its realm from the settings in the
119                      krb5.conf(4) file.
120
121
122       -s tos         Sets the IP TOS option.
123
124
125       -S keytab      Sets     the     KRB5     keytab     file     to    use.
126                      The/etc/krb5/krb5.keytab file is used by default.
127
128
129       -U             Refuses connections that cannot  be  mapped  to  a  name
130                      through the getnameinfo(3SOCKET) function.
131
132
133       -X             Disables Kerberos V5 authentication support negotiation.
134
135

USAGE

137       telnetd and in.telnetd are IPv6-enabled. See ip6(7P).
138

SECURITY

140       in.telnetd   can   authenticate   using   Kerberos  V5  authentication,
141       pam(3PAM), or both. By default, the telnet  server  will  accept  valid
142       Kerberos  V5  authentication credentials from a telnet client that sup‐
143       ports Kerberos. in.telnetd can also support an encrypted  session  from
144       such a client if the client requests it.
145
146
147       The telnet protocol only uses single DES for session protection—clients
148       request service tickets with single DES session keys. The KDC must know
149       that host service principals that offer the telnet service support sin‐
150       gle DES, which, in practice, means that such principals must have  sin‐
151       gle DES keys in the KDC database.
152
153
154       In  order  for  Kerberos authentication to work, a host/<FQDN> Kerberos
155       principal must exist for each Fully Qualified  Domain  Name  associated
156       with the telnetd server. Each of these host/<FQDN> principals must have
157       a keytab entry in the /etc/krb5/krb5.keytab file on the telnetd server.
158       An example principal might be:
159
160
161       host/bigmachine.eng.example.com
162
163
164       See kadmin(1M) or gkadmin(1M) for instructions on adding a principal to
165       a krb5.keytab file. See  for a discussion of Kerberos authentication.
166
167
168       in.telnetd uses pam(3PAM) for authentication, account management,  ses‐
169       sion management, and password management. The PAM configuration policy,
170       listed through /etc/pam.conf, specifies the  modules  to  be  used  for
171       in.telnetd. Here is a partial pam.conf file with entries for the telnet
172       command using the UNIX authentication, account management, session man‐
173       agement, and password management modules.
174
175         telnet  auth requisite          pam_authtok_get.so.1
176         telent  auth required           pam_dhkeys.so.1
177         telent  auth required           pam_unix_auth.so.1
178
179         telnet  account requisite       pam_roles.so.1
180         telnet  account required        pam_projects.so.1
181         telnet  account required        pam_unix_account.so.1
182
183         telnet  session required        pam_unix_session.so.1
184
185         telnet  password required       pam_dhkeys.so.1
186         telent  password requisite      pam_authtok_get.so.1
187         telnet  password requisite      pam_authtok_check.so.1
188         telnet  password required       pam_authtok_store.so.1
189
190
191
192       If  there  are  no entries for the telnet service, then the entries for
193       the "other" service will be used. If  multiple  authentication  modules
194       are listed, then the user may be prompted for multiple passwords.
195
196
197       For  a Kerberized telnet service, the correct PAM service name is ktel‐
198       net.
199

FILES

201       /etc/default/telnetd
202
203

ATTRIBUTES

205       See attributes(5) for descriptions of the following attributes:
206
207
208
209
210       ┌─────────────────────────────┬─────────────────────────────┐
211       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
212       ├─────────────────────────────┼─────────────────────────────┤
213       │Availability                 │SUNWtnetd                    │
214       └─────────────────────────────┴─────────────────────────────┘
215

SEE ALSO

217       login(1), svcs(1), telnet(1), gkadmin(1M), inetadm(1M), inetd(1M), kad‐
218       min(1M),   svcadm(1M),   pam(3PAM),   getnameinfo(3SOCKET),   issue(4),
219       krb5.conf(4),  pam.conf(4),   services(4),   attributes(5),   pam_auth‐
220       tok_check(5),  pam_authtok_get(5), pam_authtok_store(5), pam_dhkeys(5),
221       pam_passwd_auth(5),       pam_unix_account(5),        pam_unix_auth(5),
222       pam_unix_session(5), smf(5), ip6(7P), termio(7I)
223
224
225
226
227
228       Alexander,  S. RFC 1572, TELNET Environment Option. Network Information
229       Center, SRI International, Menlo Park, Calif., January 1994.
230
231
232       Borman, Dave. RFC 1408, TELNET Environment Option. Network  Information
233       Center, SRI International, Menlo Park, Calif., January 1993.
234
235
236       Borman,  Dave.  RFC  1571,  TELNET  Environment Option Interoperability
237       Issues. Network Information  Center,  SRI  International,  Menlo  Park,
238       Calif., January 1994.
239
240
241       Crispin,  Mark. RFC 727, TELNET Logout Option. Network Information Cen‐
242       ter, SRI International, Menlo Park, Calif., April 1977.
243
244
245       Marcy, G. RFC 1096, TELNET X Display Location Option. Network  Informa‐
246       tion Center, SRI International, Menlo Park, Calif., March 1989.
247
248
249       Postel,  Jon,  and  Joyce Reynolds. RFC 854, TELNET Protocol Specifica‐
250       tion.  Network  Information  Center,  SRI  International,  Menlo  Park,
251       Calif., May 1983.
252
253
254       Waitzman,  D.  RFC 1073, TELNET Window Size Option. Network Information
255       Center, SRI International, Menlo Park, Calif., October 1988.
256
257
258       Kohl, J., Neuman, C., The Kerberos Network Authentication Service (V5),
259       RFC 1510. September 1993.
260
261
262       Ts'o, T. and J. Altman, Telnet Authentication Option, RFC 2941. Septem‐
263       ber 2000.
264
265
266       Ts'o, T., Telnet Authentication: Kerberos Version 5, RFC 2942.  Septem‐
267       ber 2000.
268
269
270       Ts'o, T., Telnet Data Encryption Option, RFC 2946. September 2000.
271
272
273       Ts'o, T., Telnet Encryption: DES 64 bit Cipher Feedback, RFC 2952. Sep‐
274       tember 2000.
275

NOTES

277       Some TELNET commands are only partially implemented.
278
279
280       Binary mode has no common interpretation except between similar operat‐
281       ing systems.
282
283
284       The  terminal type name received from the remote client is converted to
285       lower case.
286
287
288       The packet interface to the pseudo-terminal should  be  used  for  more
289       intelligent flushing of input and output queues.
290
291
292       in.telnetd never sends TELNET go ahead commands.
293
294
295       The  pam_unix(5)  module is no longer supported.. Similar functionality
296       is  provided  by  pam_authtok_check(5),  pam_authtok_get(5),  pam_auth‐
297       tok_store(5),  pam_dhkeys(5),  pam_passwd_auth(5), pam_unix_account(5),
298       pam_unix_auth(5), and pam_unix_session(5).
299
300
301       The in.telnetd service is managed by the service  management  facility,
302       smf(5), under the service identifier:
303
304         svc:/network/telnet
305
306
307
308
309       Administrative actions on this service, such as enabling, disabling, or
310       requesting restart, can be performed using  svcadm(1M).  Responsibility
311       for  initiating  and restarting this service is delegated to inetd(1M).
312       Use inetadm(1M) to make configuration changes and to view configuration
313       information for this service. The service's status can be queried using
314       the svcs(1) command.
315
316
317
318SunOS 5.11                        10 Nov 2005                   in.telnetd(1M)
Impressum