Telnet

Standards

IETF STD 8: Telnet has been known to be a concatenation of multiple RFC documents. That will likely always be the case, unless a new RFC is created which replaces multiple old documents. Even in that case, if the new document gets updated, IETF STD 8 may again become a concatenation of multiple RFC documents.

There have been quite a few RFC's related to Telnet. Wikipedia's page on Telnet: section called “Related RFCs” lists over two dozen of them, including RFCs 854 through 861.

telnet.org: Development Resources provides a list of Telnet related RFC's.

Summary

For the most part, a telnet connection is essentially a simple TCP connection. However, the telnet protocol does allow some variation from just a simple TCP connection, such as having a Telnet client possess the ability to send a what is called a “break” signal, or the client asking the server to “echo” (repeat back) characters that are received over the main data connection.

Differences between Telnet and TCP

Telnet-specific commands may be sent, by sending an ASCII code 255 as an escape character. An actual intended ASCII code 255 must be escaped (so that two sequential ASCII 255 characters end up getting treated as one). (If this is a problem, using another protocol such as SSH, or RLogin, or raw TCP perhaps by somehow using software like Netcat, may be a better option than trying to use software that is implementing the telnet protocol.) After the ASCII 255 escape code, the next byte or two may have special meaning to software that fully understands the telnet protocol. Specifically, if the byte after the ASCII 255 escape character is a character with an ASCII value of 240 or higher, the intended meaning of the special code is documented by RFC 854 page 13, and also page 14. (More details about how the bytes are interpreted are on earlier pages of the document.)

The differences between telnet and TCP are often insignificant enough that the differences really don't matter much. (The telnet software will typically be treating most bytes as basically the same, so communications that just use bytes other than the special ASCII value of 255 can often provide an experience where no real difference (between a proper telnet connection or a raw TCP connection) is effectively noticed.) Options do may exist, like being able to echo characters back, and these options may even permit encryption to be able to performed over a Telnet application. However, these options do not usually end up interfering with a TCP connection if someone just tries to make a connection and type some commands.

So, to restate all that briefly: Although differences do eixst, they are often not significant enough to provide any noteworthy impact (neither negative nor positive). Often a telnet connection may be effectively used as a TCP connection. In fact, that has often been done by knowledgeable networking experts, who wished to use a readily available (software) tool, to perform some troubleshooting.

Using a telnet client to interact with TCP protocols

A telnet-capable client software can be effectively used to interact directly with servers of various TCP services, particularly TCP-based services that use plaintext commands and responses. There are quite a few of these that are prevelant: Examples include: SMTP, HTTP, POP3, and even IRC. Also, portions of FTP work using just a standard TCP connection. Transfering files, especially binary files, may be a bit more challenging, but logging it can certainly be attempted over telnet.

Granted, many (probably most, and even nearly all) such communications are often used for confidential information. Such information should not be transmitted over uncrypted TCP, and it may be beneficial for security if such protocols are replaced with more secure protocols. In at least some cases, instead of using such protocols with telnet software, there may be security benefits to replacing the usage of those protocols. However, despite all that, the reality is that when dealing with insecure protocols, telnet may be useful. Besides, not all information has to be encrypted: if the information is public anyway, there may be little benefit to encryption.

Other protocols that do use encryption, such as SSL communications (such as what is found when using HTTPS), may not be quite as practical to use a telnet client for making a fully accepted connection (including authenticating and transmitting encrypted bits). However, a piece of standard telnet client software can be used as a way to verify if connections made to a TCP port are successful. (Simply tell the telnet client to make a standard telnet connection.)

Using telnet as remote access

OpenSSH artwork proclaiming the (desired) end to Rlogin, Telnet, and Rsh is meant to convey a clear idea: That SSH should replace Telnet. This may be true in many cases: remote access is especially one of the cases. Passwords are sent in plaintext and so may be automatically and silently captured. A MITM attack could even allow a system that relays traffic to mimic the client and the server, changing any communications as desired. (Any byte seen by the client would be what the attacker wants the client to receive, and the server would only receive what the attacker wants the server to see.) Either of these attacks could potentially occur without any visible indication (to either the client or the server) that there's any problem occurring.

To check things out historically, or if using an entirely controlled network/subnet that is protected from any possibly malicious communications, a server may be set up. A standard (meaning common, and possibly expected) telnet server may provide access to a command line shell. There are certainly other types of services that could be provided over a telnet server, such as a BBS (possibly using updated versions of old BBS software that listened to phone lines in the early 1990s). (Note that although using a BBS is feasible, one popular activity was to transfer binary files; that may often not work quite so well over a telnet connection.)

Software may include telnetd for Unix. (For Microsoft Windows, some operating systems may come with a telnet server administrable using tlntadmn: see TechNet Documentation: Command-line Reference for Telnet Server.

OpenBSD no longer comes with a telnet server. (It used to: OpenBSD 3.7 Manual Page for telnetd”. However, the concept must have seemed too insecure: CVS update shows project leader Theo DeRaadt saying “bye bye” to the telnet code.) (It is unclear, therefore, why, over five years later, a mailing list archive shows telnetd OpenBSD improvements from October, 2010.) An option may be a package called “stel”.

How to use a telnet client

Note: A lot of the software that supports SSH may also support Telnet. In some cases, such software may also typically provide a nicer interface. The key advantage to using Telnet-only software is that in some operating systems, including Microsoft Windows and some older operating systems, a Telnet client may be pre-bundled, while an SSH client might not be. So, this section describes some of the software options for Telnet, and these options are often recommended only because of their convenience. People who will be using the software extensively might wish to invest the time in getting a preferred, pleasant piece of client software. (This is perhaps mostly noted for users of Microsoft Windows, where many people prefer to use PuTTY.)

Client Software
[#mswnbdtl]: Using a telnet client from Microsoft Windows

At least some versions of Microsoft Windows come with a traditional telnet client that runs from the command line and, in theory, acts quite similar to a traditional telnet client running in Unix. However, (with at least some versions of Microsoft Windows) this software has some terminal emulation issues that can make the experience notably unpleasant. Using other software is recommended. Some versions of Microsoft Windows, including Windows 95 through Windows ME, and also Windows XP, came with some software called HyperTerminal.

Microsoft page about HyperTerminal

However, one nice thing about the software is that it does come with the operating system. In newer versions of the operating system, by default this software might not be available until being installed. This may be done using a graphical interface, or just quickly installing a Windows feature from the command line. (The Installing software bundled with Microsoft Windows provides the “ Dism /online /enable-feature /featurename:TelnetClient ” command line. Other options may be described in nearby documentation, such as installing Roles and Features in Microsoft Windows.)

Default telnet application (multiple operating systems)

Many operating systems come with a command called telnet. This tends to be a simplistic implementation.

Installation
Many operating systems have this software installed by default.

Operating systems that include this basic telnet program include multiple Microsoft Windows versions, from Windows 95 up to (and including) Microsoft Windows XP. Microsoft Windows Vista and newer will often not have the software completely installed by default, but the software may be readily available and relatively easily installable, which can be done using information about “Deployment Image Servicing and Management” (“Dism”) in the section about “Software Installation”.

Command line syntax/option(s)

A typical traditional telnet client will accept command line parameters. To connect to a remote system at a specified TCP port, use:

telnet remoteNameOrIPAddress optionalTCPPortNumber

This basic syntax can be used to connect to the specified remote system. If the optional TCP port number is ommitted, then TCP port 23 is used.

Another example, closer to what would actually be typed, is:

telnet remote.example.com 23
Program Usage (while running)

If the telnet command is started without command line parameters, it may present the user with a prompt such as “telnet> ” (or some sort of variation, such as “Microsoft Telnet> ” if using the Microsoft telnet client bundled with an operating system such as Windows Vista). From this prompt, various commands may be provided, including help to show various commands and the ever-popular quit which quits the entire telnet program. (Typically, the telnet program is often run from a command prompt. Naturally, once the telnet program quits, the user interface will again become interaction with the command prompt.)

Once connected, the user interface typically shows the connection, so the user is not able to interact directly with the prompt unless the telnet client is instructed to show a “telnet> ” prompt again instead of the characters received over the TCP connection. The way to provide such an instruction to the telnet client is to hold the Ctrl key and press the right square bracket key (Ctrl-]). (Then, after pressing and releasing the ] key, release the Ctrl key. The prompt may show up before the Ctrl key is released.)

Looking at a possible alternative: In Microsoft Windows, unlike holding Alt and pressing 29, this character sequence does not typically send the double horizontal arrow character out the TCP connection, but rather tells the client software to show that prompt. So, in Microsoft Windows, the Ctrl-] keyboard input is checked for, not just any occurrance of ASCII 29. (This was tested, both by using the operating system's clipboard to paste the character, as well as the quicker and less clobbering technique of using Alt with the numpad to generate an ASCII character to make ASCII 29.) However, in a Unix-type of environment, as reached via a PuTTY SSH connection and then running telnet on a Linux-based machine, sending ASCII code 29 did seem to escape to the telnet's “telnet> ” prompt. So, that program did seem to treat ASCII 29 as being the same thing as a keyboard “Ctrl” sequence, identical as pressing Ctrl-].

If a “telnet> ” prompt is showing while there is an active telnet connection being handled by the telnet client, then entering a blank command (by pressing Enter with no other command on the command line) will again start showing the bytes of the connection.

Using a web client

Note: Anyone using a web client because they are not sufficiently comfortable with installing dedicated software should probably be informed/reminded that Telnet does not encrypt traffic. (Telnet offers few enhancements over a raw, unfiltered TCP connection, so the resulting traffic is typically sniffable. This means that passwords can be captured and seen immediately or later, as well as all other characters that are received or sent.)

However, skipping the requirement to perform a traditional installation can be useful in some cases, such as when using a computer system that has security measures that prohibit a traditional “installation”.

HtmlTerm/fTelnet

HtmlTerm and fTelnet is a website that was originally about fTelnet, although now HtmlTerm seems to be promoted more heavily. The main page talks about the software, while the sub-page called My fTelnet provides a usable example.

Using “My fTelnet”

Choose “Add a new entry”, then use the “Save” button (which shows part of a floppy disk, with a checkbox). That causes a new entry to show up in the “My Address Book” section.

Before connection, try out the “Settings” page to choose a specific proxy. This is an optional step but one that is likely to result in increased speed. (Once a proxy site is chosen, there doesn't seem tobe an intuitive way, using the web site's hyperlinks, to reset the choice back to blank/unspecified.)

Click the hyperlink of the new Address Book entry to connect.

When creating the address book entry, leave the “Connect via proxy? (See the Settings page for more info)” checkbox checked if you are trying to use Telnet to c onnect to the remote system. The checkbox is just there as an easy way to connect to the remote system using WebSocket (instead of “My fTelnet” using WebSocket to connect to a proxy which then connects via Telnet).

Some other available Telnet clients

Hilgraeve software telnet support exists in at least some versions of HyperTerminal. They are particularly noteworthy due to having software bundled with some versions of Microsoft Windows (including Windows 95 and Windows Server 2003). It could be used as a default telnet client for web browsers (as noted by TechNet documentation about HyperTerminal: information about which telnet client is the default).

Quite a few pieces of software which support other methods of connecting to remote shells will also support telnet. A popular implementation, especially for Microsoft Windows (but also available for other platforms, e.g. OpenBSD) is PuTTY, which also supports SSH and so is listed in the SSH section. (See: PuTTY for Microsoft Windows and/or PuTTY for Unix.) VanDyke software had a program called CRT, which stood for Combined RLogin and Telnet, which is some older software that even worked with Windows 3.1. It seems that software has since added SSH support as well (and has a Mac OS X version), and the new version is called SecureCRT.

For those who are interested in an experience similar to old BBS's, support for automatic Z-Modem downloads is supported by:

Other software options are listed on TOOGAM's archive of terminal software and Wikipedia's page for telnet: section on clients.

One may try opening up a web browser and seeing if a protocol handler is installed for the telnet:// protocol.

At least some versions of Windows come with a “telnet” program (note: is this a GUI program? as compared to the text mode program?) which offers quite awful terminal emulation. (It is quite likely that the terminal emulation is buggy.) The recommended approach is to either download another client or use HyperTerm (if that's available?). TechNet Documentation about the telnet client from Windows Server 2003.

Server software
[#ciostlnd]: Cisco IOS Telnet server

First, since these directions are rather specific to Cisco IOS, there is the standard warning about directions related to Cisco IOS. (Don't waste your time trying to apply these directions if professional-grade Cisco equipment is not being involved.)

The directions are fairly similar to getting an SSH server to work with Cisco IOS, so the directions won't be completely repeated here. The main differences to note are:

  • You don't need to generate the SSH key, so skip that step
  • There may be some IOS images that don't support encryption. So, since those IOS images don't support encryption, they can support Telnet, but not SSH. So Telnet can run on that equipment.
  • Just make sure that the transport line mentions telnet. (Further details about this line are described in the directions for getting an SSH server to work with Cisco IOS.)
  • Obviously, for testing this, the telnet command built into IOS would be more useful than the ssh command built into some versions of IOS.
Encryption

A lot of people will say that Telnet does not support encryption. Well, actually that's not entirely true: encryption is supported as an official option for Telnet, as evidenced by RFC 2946: “Telnet Data Encryption Option”, and IANA: Telnet Options 10: Telnet Encryption Types (Option 38). Different options are mentioned by RFC 2946 - RFC 2950 (including RFC 2947, RFC 2948, and RFC 2949), as well as both RFC 2952 and RFC 2953.

To clarify: it may well be that the basic protocol of Telnet, as specified by RFC 854: Telnet, has no encryption feature. However, at a later time, some Telnet options were created, and some of those options support encryption. So, it is entirely possible to use encryption on an authentic Telnet connection (by using options), but that doesn't mean that encryption is a feature that is built into the base (simple) Telnet protocol.

It appears that support for encryption in Telnet is something that most people just never got very excited about. Just because the protocol supports an “option” does not mean that every client needs to implement that option. In fact, it seems many don't: an answer by Barmar on the StackOverflow site notes, “encryption and authentication” ... “are available as options in TELNET, but adoption is spotty).” RFC 2941 page 2 mentions SSL as an authentication command that has a reserved number, which which was “never submitted to the IETF for consideration as an Internet standard.” (Maybe there was no implementation created?)

Instead, as the widely touted/promoted advice states, the popular way to handle encryption is to use SSH, which is a newer protocol that has replaced many, many uses that TELNET was previously used for.

From the description of TechNet blog about using Telnet over IPSec, it sounds like Microsoft demonstrated protecting Telnet traffic using other encryption (provided by IPSec).