Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 16 ■ TELNET AND SSH
• The more powerful and sophisticated expect() method takes a list of Python
regular expressions. Once the text arriving from the remote end finally adds up to
something that matches one of the regular expressions, expect() returns three
items: the index in your list of the pattern that matched, the regular expression
SRE_Match object itself, and the text that was received leading up to the matching
text. For more information on what you can do with a SRE_Match, including finding
the values of any sub-expressions in your pattern, read the Standard Library
documentation for the re module.
Regular expressions, as always, have to be written carefully. When I first wrote this script, I used '$'
as the expect() pattern that watched for the shell prompt to appear—which, of course, is a special
character in a regular expression! So the corrected script shown in the listing escapes the $ so that
expect() actually waits until it sees a dollar sign arrive from the remote end.
If the script sees an error message because of an incorrect password—and does not get stuck waiting
forever for a login or password prompt that never arrives or that looks different than it was expecting—
then it exits:
$ python telnet_login.py
Username and password failed - giving up
If you wind up writing a Python script that has to use Telnet, it will simply be a larger or more
complicated version of the same simple pattern shown here.
Both read_until() and expect() take an optional second argument named timeout that places a
maximum limit on how long the call will watch for the text pattern before giving up and returning
control to your Python script. If they quit and give up because of the timeout, they do not raise an error;
instead—awkwardly enough—they just return the text they have seen so far, and leave it to you to figure
out whether that text contains the pattern!
There are a few odds and ends in the Telnet object that we need not cover here. You will find them
in the telnetlib Standard Library documentation—including an interact() method that lets the user
“talk” directly over your Telnet connection using the terminal! This kind of call was very popular back in
the old days, when you wanted to automate login but then take control and issue normal commands
yourself.
The Telnet protocol does have a convention for embedding control information, and telnetlib
follows these protocol rules carefully to keep your data separate from any control codes that appear. So
you can use a Telnet object to send and receive all of the binary data you want, and ignore the fact that
control codes might be arriving as well. But if you are doing a sophisticated Telnet-based project, then
you might need to process options.
Normally, each time a Telnet server sends an option request, telnetlib flatly refuses to send or
receive that option. But you can provide a Telnet object with your own callback function for processing
options; a modest example is shown in Listing 16–4. For most options, it simply re-implements the
default telnetlib behavior and refuses to handle any options (and always remember to respond to each
option one way or another; failing to do so will often hang the Telnet session as the server waits forever
for your reply). But if the server expresses interest in the “terminal type” option, then this client sends
back a reply of “mypython,” which the shell command it runs after logging in then sees as its $TERM
environment variable.
Listing 16–4. How to Process Telnet Option Codes
#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 16 - telnet_codes.py
# How your code might look if you intercept Telnet options yourself
from telnetlib import Telnet, IAC, DO, DONT, WILL, WONT, SB, SE, TTYPE
277