TELNETD(8)

💖 TELNETD(8) — System Manager's Manual 💖

okay so before we even get into it: this is TELNETD(8), straight out of the System Manager's Manual, and it is the granddaddy situation for remote logins. bestie, this manpage is long, so buckle up — we're doing this in parts. ✨

---

🌸 NAME 🌸

in.telnetd — the DARPA TELNET protocol server. yes, that's the whole name. it's giving "i've been here since the beginning of the internet and i have the receipts." no cap. 🎀

ngl the vibes are immaculate but also slightly historical — it's a server, so it's the one doing the listening, not the one knocking on the door.

---

🦋 SYNOPSIS 🦋

here's the summoning ritual, character for character, exactly as written:

in.telnetd [-Uhlkn46H] [-D debugmode] [-Iinitid] [-S tos] [-X authtype]
           [-rlowpty-highpty] [-u len] [-L /bin/login] [-debug [port]]

lowkey a lot of little letters, ik, but they're all going to get their moment. some quick observations so you're not caught off guard:

• that first cluster — -Uhlkn46H — is just a bunch of short flags holding hands 💅
• -D debugmode and -Iinitid are the ones that take a value stuck right onto them with no space, so like -D + whatever the debug mode is. same energy for -I + the init id.
• -S tos takes a tos value, -X authtype takes an authtype, and -u len takes a len (that's a length, bestie).
• -rlowpty-highpty is the cutest one: a literal lowpty and highpty glued together by a hyphen inside a single flag. it's giving range. 🍓
• -L /bin/login lets you point at a different login binary — that path right there is the default-looking one, keep it in your pocket.
• -debug [port] is the long-form debug situation, and port is optional — it's sitting in brackets because it might not be there at all.

that's the whole silhouette! the options themselves get the full glow-up in the next part, so don't go anywhere. 💜

✨ DESCRIPTION ✨

okay so bestie, picture this: in.telnetd is a server, and it's out here supporting the DARPA standard TELNET virtual terminal protocol. icon behavior honestly 👑

Normally? It gets invoked by the internet server (peep inetd(8)) whenever there's a request to connect to the TELNET port — the one listed in the /etc/services file (see services(5)). But if you're feeling brave and want to start in.telnetd manually instead of going through inetd(8), you can use the -debug option. and if you do start it that way, you can pass port to run in.telnetd on an alternate TCP port number. main character energy 🔥

The in.telnetd command accepts the following options:

• -D debugmode — this one's purely for debugging purposes. It lets in.telnetd print out debugging information straight to the connection, so you can literally watch what in.telnetd is doing in real time. There are several possible values for debugmode:
  • options — prints information about the negotiation of TELNET options.
  • report — prints the options information, plus some additional information about what processing is going on.
  • netdata — displays the data stream received by in.telnetd.
  • ptydata — displays data written to the pty.
  • exercise — 💀 has not been implemented yet. (sorry bestie)
• -debug — enables debugging on each socket created by in.telnetd (see SO_DEBUG in socket(2)).
• -h — disables the printing of host-specific information before login has been completed. privacy era 💅
• -H — instruct the login program to suppress printing the hostname before the prompt.
• -I initid — heads up, this option is only applicable to UNICOS systems prior to 7.0. It specifies the ID from /etc/inittab to use when init starts login sessions. The default ID is "fe".
• -k — this option is only useful if in.telnetd has been compiled with both linemode and kludge linemode support. If -k is specified, then if the remote client does not support the LINEMODE option, in.telnetd will operate in character at a time mode. It will still support kludge linemode, but will only go into kludge linemode if the remote client requests it. (this is done by the client sending DONT SUPPRESS-GO-AHEAD and DONT ECHO.) The -k option is most useful when there are remote clients that do not support kludge linemode, but pass the heuristic (if they respond with WILL TIMING-MARK in response to a DO TIMING-MARK) for kludge linemode support. ikyk ikyk 🧚
• -l — specifies line mode. Tries to force clients to use line-at-a-time mode. If the LINEMODE option is not supported, it will go into kludge linemode.
• -n — disable TCP keep-alives. Normally in.telnetd enables the TCP keep-alive mechanism to probe connections that have been idle for some period of time to determine if the client is still there, so that idle connections from machines that have crashed or can no longer be reached may be cleaned up. it's giving ghosting, but make it networking 👻
• -r lowpty-highpty — this option is only enabled when in.telnetd is compiled for UNICOS. It specifies an inclusive range of pseudo-terminal devices to use. If the system has sysconf variable _SC_CRAY_NPTY configured, the default pty search range is 0 to _SC_CRAY_NPTY; otherwise, the default range is 0 to 128. Either lowpty or highpty may be omitted to allow changing either end of the search range. If lowpty is omitted, the - character is still required so that in.telnetd can differentiate highpty from lowpty. no skipping the dash bestie, it's load-bearing 😭
• -S tos — (bestie the page literally gives us zero description for this one, so I'm not about to make something up. it's just sitting there being mysterious. leaving it exactly as-is fr fr 🙈)
• -u len — this option is used to specify the size of the field in the utmp structure that holds the remote host name. If the resolved host name is longer than len, the dotted decimal value will be used instead. This allows hosts with very long host names that overflow this field to still be uniquely identified. Specifying -u0 indicates that only dotted decimal addresses should be put into the utmp file.
• -U — this option causes in.telnetd to refuse connections from addresses that cannot be mapped back into a symbolic name via the gethostbyaddr(3) routine. no name? no entry. periodt 🚫
• -X authtype — this option is only valid if in.telnetd has been built with support for the authentication option. It disables the use of authtype authentication, and can be used to temporarily disable a specific authentication type without having to recompile in.telnetd. so convenient honestly 💖
• -L pathname — specify pathname to an alternative login program.
• -4 — (again, no description on the page for this one 😭 just vibes and a number. not inventing anything!)
• -6 — specifies address family to be used on -debug mode. During normal operation (called from inetd(8)) in.telnetd will use the file descriptor passed from inetd(8).

---

in.telnetd operates by allocating a pseudo-terminal device (see pty(4)) for a client, then creating a login process which has the slave side of the pseudo-terminal as stdin, stdout, and stderr. in.telnetd manipulates the master side of the pseudo-terminal, implementing the TELNET protocol and passing characters between the remote client and the login process. it's a whole middleman situation and honestly it's slaying 🫶

When a TELNET session is started up, in.telnetd sends TELNET options to the client side indicating a willingness to do the following TELNET options, which are described in more detail below:

DO AUTHENTICATION
WILL ENCRYPT
DO TERMINAL TYPE
DO TSPEED
DO XDISPLOC
DO NEW-ENVIRON
DO ENVIRON
WILL SUPPRESS GO AHEAD
DO ECHO
DO LINEMODE
DO NAWS
WILL STATUS
DO LFLOW
DO TIMING-MARK

The pseudo-terminal allocated to the client is configured to operate in cooked mode, and with XTABS and CRMOD enabled (see tty(4)).

🌸 locally enableable TELNET options 🌸

in.telnetd has support for enabling locally the following TELNET options:

• WILL ECHO — when the LINEMODE option is enabled, a WILL ECHO or WONT ECHO will be sent to the client to indicate the current state of terminal echoing. When terminal echo is not desired, a WILL ECHO is sent to indicate that in.telnetd will take care of echoing any data that needs to be echoed to the terminal, and then nothing is echoed. When terminal echo is desired, a WONT ECHO is sent to indicate that in.telnetd will not be doing any terminal echoing, so the client should do any terminal echoing that is needed. yes this is confusing, no I'm not sorry, it's literally what it says 💀
• WILL BINARY — indicates that the client is willing to send a 8 bits of data, rather than the normal 7 bits of the Network Virtual Terminal.
• WILL SGA — indicates that it will not be sending IAC GA, go ahead, commands.
• WILL STATUS — indicates a willingness to send the client, upon request, of the current status of all TELNET options.
• WILL TIMING-MARK — whenever a DO TIMING-MARK command is received, it is always responded to with a WILL TIMING-MARK.
• WILL LOGOUT — when a DO LOGOUT is received, a WILL LOGOUT is sent in response, and the TELNET session is shut down. bye bestie ✨
• WILL ENCRYPT — only sent if in.telnetd is compiled with support for data encryption, and indicates a willingness to decrypt the data stream.

🦋 remotely enableable TELNET options 🦋

in.telnetd has support for enabling remotely the following TELNET options:

• DO BINARY — sent to indicate that in.telnetd is willing to receive an 8 bit data stream.
• DO LFLOW — requests that the client handle flow control characters remotely.
• DO ECHO — this is not really supported, but is sent to identify a 4.2BSD telnet(1) client, which will improperly respond with WILL ECHO. If a WILL ECHO is received, a DONT ECHO will be sent in response. it's a trap detector basically 😭
• DO TERMINAL-TYPE — indicates a desire to be able to request the name of the type of terminal that is attached to the client side of the connection.
• DO SGA — indicates that it does not need to receive IAC GA, the go ahead command.
• DO NAWS — requests that the client inform the server when the window (display) size changes.
• DO TERMINAL-SPEED — indicates a desire to be able to request information about the speed of the serial line to which the client is attached.
• DO XDISPLOC — indicates a desire to be able to request the name of the X windows display that is associated with the telnet client.
• DO NEW-ENVIRON — indicates a desire to be able to request environment variable information, as described in RFC 1572.
• DO ENVIRON — indicates a desire to be able to request environment variable information, as described in RFC 1408.
• DO LINEMODE — only sent if in.telnetd is compiled with support for linemode, and requests that the client do line by line processing.
• DO TIMING-MARK — only sent if in.telnetd is compiled with support for both linemode and kludge linemode, and the client responded with WONT LINEMODE. If the client responds with WILL TM, the it is assumed that the client supports kludge linemode. Note that the [-k] option can be used to disable this.
• DO AUTHENTICATION — only sent if in.telnetd is compiled with support for authentication, and indicates a willingness to receive authentication information for automatic login.
• DO ENCRYPT — only sent if in.telnetd is compiled with support for data encryption, and indicates a willingness to decrypt the data stream.

🎀 FILES 🎀

• /etc/services
• /etc/inittab (UNICOS systems only)
• /etc/iptos (if supported)

👑 SEE ALSO 👑

login(1), telnet(1)

✨ STANDARDS ✨

okay so bestie, in.telnetd is not just vibing on its own — it's literally built on a whole stack of RFCs and it respects them. here's the full syllabus, no skips:

• RFC-854 — TELNET PROTOCOL SPECIFICATION
• RFC-855 — TELNET OPTION SPECIFICATIONS
• RFC-856 — TELNET BINARY TRANSMISSION
• RFC-857 — TELNET ECHO OPTION
• RFC-858 — TELNET SUPPRESS GO AHEAD OPTION
• RFC-859 — TELNET STATUS OPTION
• RFC-860 — TELNET TIMING MARK OPTION
• RFC-861 — TELNET EXTENDED OPTIONS - LIST OPTION
• RFC-885 — TELNET END OF RECORD OPTION
• RFC-1073 — Telnet Window Size Option
• RFC-1079 — Telnet Terminal Speed Option
• RFC-1091 — Telnet Terminal-Type Option
• RFC-1096 — Telnet X Display Location Option
• RFC-1123 — Requirements for Internet Hosts -- Application and Support
• RFC-1184 — Telnet Linemode Option
• RFC-1372 — Telnet Remote Flow Control Option
• RFC-1416 — Telnet Authentication Option
• RFC-1411 — Telnet Authentication: Kerberos Version 4
• RFC-1412 — Telnet Authentication: SPX
• RFC-1571 — Telnet Environment Option Interoperability Issues
• RFC-1572 — Telnet Environment Option

like, yes, it's a reading list 😭 but the protocol girlies know iykyk 💅

---

💀 BUGS 💀

ngl, it's not all slay. here's the receipts 🧾

• Some TELNET commands are only partially implemented. not a full vibe, more of a situationship.
• Because of bugs in the original 4.2 BSD telnet(1), in.telnetd performs some dubious protocol exchanges to try to discover if the remote client is, in fact, a 4.2 BSD telnet(1). it's giving detective era, lowkey doing the most 🔍
• Binary mode has no common interpretation except between similar operating systems (Unix in this case). so like, keep it in the family 🫶
• The terminal type name received from the remote client is converted to lower case. that's just the rules, don't fight it.
• in.telnetd never sends TELNET IAC GA (go ahead) commands. not once. not ever. periodt.
• WONT CRYPT. in.telnetd talks over insecure, unencrypted communications channels. this is the important one, so listen up:

🚨 bestie please, use sshd(8) instead. this is not a drill, the traffic is literally in plaintext out in the open, do NOT send your secrets through here 😭💀

---

and that's the whole page, we ate and left no crumbs 💅✨ she's a Debian original from March 1, 1994, filed under TELNETD(8) — vintage icon behavior, honestly 👑🦋 go use sshd though, fr fr 🌸