Protocol Deep Dive: SSH and Telnet

Course Overview
Hi there. Do you ever get the irrepressible urge to reach out and connect? Well, if the connections you're after involve servers, remote computers, or stripped-down development devices, then the odds are pretty good that there's going to be an SSH or Telnet session coming soon into your busy social life. But what do you do when things don't work out? What's the plan when your request is refused, if the host doesn't respond, or if your session suddenly times out? When should you be using Telnet, a protocol that, after all, is nearly 50 years old, and when should you not? The SSH and Telnet networking protocols are mature and absolutely reliable tools for handling remote connectivity, but understanding how they're built and what kind of care and feeding they'll need to keep them happy involves a bit of a learning curve. In this course, I'll introduce you to the basic design and function of the two protocols and present some common problems and their solutions, along with some helpful troubleshooting techniques. If you've got a basic knowledge of TCP/IP and a couple of virtual or physical machines to play with and you want to learn how to dig yourself out when your remote connections go wrong, then this is a course worth taking.

The Telnet Protocol
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.