Chapter 5
SSH
It seems like SSH, Secure Shell, has been around forever; it certainly has been around for a long
time in UNIX/Linux circles. Many network devices are built on a proprietary UNIX-like OS, so
it makes sense that many would therefore incorporate SSH. SSH provides a way for one
computer to log on to another, in order to execute commands on the remote computer. In terms
of network management, SSH provides a secure means of logging on to network devices in order
to control them and alter their configuration.
SSH isn't defined in an RFC; it has been a standard component of most UNIX implementations for
years. You can read a description of it at
With regard to the IETF, SSH is defined in an Internet-Draft (actually several of them) that you can
access at
.
SSH Theory of Operation
There are two versions of SSH in widespread use: SSH1 and SSH2. The two are drastically
different in terms of their underlying workings:
· For encryption, SSH1 uses DES and SSH2 can use either DES or Triple-DES (3DES).
SSH1 can also use lesser-known cipher algorithms such as IDEA and Blowfish; SSH2
supports Blowfish, Twofish, Arcfour, and Casr128-cbc.
· For authentication, SSH1 uses RSA encryption and SSH2 uses DSA.
Both versions authenticate using a variety of techniques:
· A password file (such as /etc/passwd in UNIX implementations)
· A user's public key (RSA or DSA, depending on the SSH version)
· Kerberos (SSH1 only)
Practically speaking, network devices will tend to use the first technique or combine SSH with
RADIUS- or TACACS-based authentication.
SSH consists of several sub-protocols:
· SSH-TRANS--Provides server authentication, encryption, and integrity; this transport-
layer protocol can also provide data compression.
· SSH-USERAUTH--Provides user-to-server authentication and runs over SSH-TRANS
· SSH-CONNECT--Runs over the SSH-USERAUTH protocol and multiplexes the
encrypted tunnel into several logical communications channels
A key concept in SSH is that of the host key. Each server (or network device) accepting SSH
connections should have a host key, which serves as the basis for identification. SSH sessions
begin with a key exchange, and the host key allows a client to verify that the client is talking to
the server it intended--thus preventing an attacker from spoofing the server and capturing a
client connection. Of course, the client must have prior knowledge of the correct key for
comparison purposes. In practice, clients generally obtain this prior knowledge from a local
database that associates each host name with a public host key. Other techniques, including the
use of public certification authorities, exist but are generally not practical in terms of a network
device's internal SSH implementation.
93