Protocol Deep Dive: SSH and Telnet

If you need to connect remotely to your servers and network devices, then SSH and Telnet are tools you can't ignore. Learn how the protocols work, and how to troubleshoot when they don't.
Course info
Rating
(44)
Level
Intermediate
Updated
Aug 18, 2016
Duration
41m
Table of contents
Description
Course info
Rating
(44)
Level
Intermediate
Updated
Aug 18, 2016
Duration
41m
Description

Remote connectivity is a basic and critical tool for just about any modern technology task, and the SSH - and to a much lesser degree, Telnet - protocols can play large parts in connectivity solutions. However, the complexity of network infrastructure means that establishing and maintaining reliable connections can sometimes be challenging. This course, Protocol Deep Dive: SSH and Telnet, will help you overcome those challenges. You'll start with some SSH connectivity troubleshooting and debugging, as well as care and feeding of the Wireshark network monitoring tool. You'll also get to see the Telnet remote communication protocol, when to use it...and when to avoid it. After completing this course, you'll be able to describe the basic design and function of both SSH and Telnet, tackle some common problems, and have experienced some helpful troubleshooting techniques.

About the author
About the author

David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.

More from the author
Getting Started with Linux
Beginner
1h 44m
Jan 26, 2019
More courses by David Clinton
Section Introduction Transcripts
Section Introduction Transcripts

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.