Security

In the early days of telnet (early 1980’s), most of its users were internal networks users in the computer departments of academic institutions, or at large private and government research facilities. In this environment, security was not nearly as much of a concern as it became in the 1990’s, when the internet quickly spread across the globe.

The telnet protocol raises three main security problems:

• Commonly used telnet daemons have several vulnerabilities discovered over the years, and probably several more still exist.
• telnet does not encrypt any data sent over the connection (including passwords), and so it is trivial to eavesdrop on the communications and use the password later for malicious purposes.
• telnet lacks an authentication scheme that makes it possible to ensure that communication is carried out between the two desired hosts, and not intercepted in the middle (also known as “man in the middle” attacks).

As a result, telnet is hardly used today in open, public environments where security is important (for example, the Internet). Since telnet sessions are unencrypted, it means that anybody who has access to any router, switch, or gateway located on the network between the two hosts where telnet is being used can intercept the telnet packets passing by and easily obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Ethereal.

Instead of telnet, a newer, secured protocol is used. This protocol is SSH (Secure Shell or Secure Socket Shell), released in 1998. SSH provides all functionality present in telnet and wraps it in a secured layer, with a strong encryption to prevent sensitive data such as passwords from being intercepted, and public key authentication, to ensure that the remote computer is actually who it claims to be.