While SSH, at least for UNIX-based servers,
is certainly the dominant, remote connectivity protocol,
Telnet is still out there and shouldn't be ignored.
In this module,
I'm going to talk about when it might still make sense to use Telnet,
and when it most definitely won't.
I'll also explain how the protocol works and how it's controlled,
and then we'll cover some troubleshooting scenarios.
From an historical perspective,
Telnet's greatest contribution might have been standardization.
In the days before IT hardware manufacturing could leverage the
massive scale that now provides us with the joys of industry-wide
compatibility and before freely available modular software
connectivity tools became available,
Networks were made up of all kinds of keyboard layouts,
display sizes, and session protocols, besides the usual unpredictable wild cards,
like latency.
Accommodating everything that was thrown at it required
that Telnet be very clearly defined.
Close integration with the rich transport facilities of the TCP
architecture was another part of their secret sauce.
But restricting standard communication to the rather limited ASCI character set,
operating by default across Port 23, and universally implementing NVTs,
Network Virtual Terminals,
to reliably translate the display and keyboard code specific to
host operating systems and hardware profiles,
were also big factors.
Partly because of its symmetrical design,
strictly speaking,
it doesn't actually designate hosts and clients and leaves login
logistics to the connected operating systems; Telnet can be used
for a very wide range of connections.
Although as I mention,
the number of actual real-world deployments has
cratered over the last 20 years or so.
But in the age that largely predated standard protocols, Telnet blazed an important operational path.