Chapter 16 ■ telnet and SSh299In case you make your terminal settings a hopeless mess after some experimentation, most Unix systems
provide a command for resetting the terminal to reasonable, sane settings. (Note that if you have played with stty
too severely, you might need to hit Ctrl+J to submit the reset command since your Return key, whose equivalent is
Ctrl+M, actually functions only to submit commands because of a terminal setting called icrnl.)
$ reset
If instead of trying to get the terminal to behave across a Telnet or SSH session you happen to be talking to a
terminal from your own Python script, check out the termios module that comes with the Standard Library. By
puzzling through its example code and remembering how Boolean bitwise math works, you should be able to control
all of the same settings that you just accessed through the stty command.
This book lacks the space to look at terminals in any further detail (since one or two chapters of examples
could easily be inserted right here to cover just the more interesting techniques and cases), but there are lots of
great resources for learning more about them—a classic is Chapter 19, “Pseudo Terminals,” of W. Richard Stevens’
Advanced Programming in the UNIX Environment (Addison-Wesley Professional, 1992).
Telnet
This brief section is all you will find in this book about the ancient Telnet protocol. Why? It is insecure: anyone
watching your Telnet packets fly by will see your username, password, and everything you do on the remote system.
It is clunky, and it has been completely abandoned for most systems administration.
■ THE TELNET PROTOCOL
purpose: remote shell access
Standard: rFC 854 (1989)
runs atop: tCp/Ip
default port: 23
library: telnetlib
exceptions: socket.error, socket.gaierror, eOFerror, select.error
The only time I ever find myself needing Telnet is when communicating with a small, embedded system, like a Linksys
router or DSL modem or network switch deep inside a well-firewalled corporate network. In case you have to write a Python
program that has to speak Telnet to one of these devices, here are a few pointers on using the Python telnetlib.
First, you have to realize that all Telnet does is to establish a channel—in fact, a fairly plain TCP socket (see
Chapter 3)—and then copy information in both directions across that channel. Everything you type is sent out across
the wire, and Telnet prints to the screen everything it receives. This means Telnet is ignorant of all sorts of things about
which you might expect a remote-shell protocol to be aware.
For example, it is commonplace that when you Telnet to a Unix machine, you are presented with a login:
prompt at which you type your username and then a password: prompt where you enter your password. The small,
embedded devices that still use Telnet nowadays might follow a slightly simpler script, but they too often ask for some
sort of password or authentication. Either way, Telnet itself knows nothing about this pattern of exchange! To your
Telnet client, password: is just nine random characters that come flying across the TCP connection and that it must
print to your screen. It has no idea that you are being prompted, that you are responding, or that, in a moment, the
remote system will know who you are.