The Secure Shell (SSH)

The Secure Shell
(SSH)
To tackle the issue of remote login versus password security, a solution called Secure
Shell (SSH) was developed. SSH is a suite of network communication tools that are col-
lectively based on an open protocol/standard that is guided by the Internet Engineer-
ing Task Force (IETF). It allows users to connect to a remote server just as they would
using Telnet, rlogin, FTP, etc.—except that the session is 100 percent encrypted. Someone
using a packet sniffer merely sees encrypted traffic going by. Should they capture the
encrypted traffic, decrypting it could take a long time.
In this chapter, we’ll take a brief and general look at the cryptography concept. Then
we’ll examine the versions of SSH, where to get it, and how to install and configure it.
UNDERSTANDING PUBLIC KEY CRYPTOGRAPHY
A quick disclaimer is probably necessary before proceeding: “This chapter is by no means
an authority on the subject of cryptography and, as such, is not the definitive source for
cryptography matters.” What you will find here is a general discussion along with some
references to good books that approach the topic more thoroughly.
Secure Shell relies on a technology called public-key cryptography. It works similarly to a
safe deposit box at the bank: You need two keys to open the box, or at least multiple layers
of security/checks have to be crossed. In the case of public-key cryptography, you need
two mathematical keys: a public one and a private one. Your public key can be published
on a public web page, printed on a T-shirt, or posted on a billboard in the busiest part of
town. Anyone who asks for it can have a copy. On the other hand, your private key must
be protected to the best of your ability. It is this piece of information that makes the data
you want to encrypt truly secure. Every public key/private key combination is unique.
The actual process of encrypting data and sending it from one person to the next requires
several steps. We’ll use the popular Alice and Bob analogy, and go through the process one
step at a time as they both try to communicate in a secure manner with one another. Fig-
ures 21-1 through 21-5 illustrate an oversimplified version of the actual process
Looking at these steps, notice that at no point was the secret (private) key sent over
the network. Also note that once the data was encrypted with Bob’s public key and
signed with Alice’s private key, the only pair of keys that could decrypt and verify it
were Bob’s private key and Alice’s public key. Thus, if someone intercepted the data in
the middle of the transmission, they wouldn’t be able to decrypt the data without the
proper private keys.
To make things even more interesting, SSH regularly changes its session key. (This
is a randomly generated, symmetric key for encrypting the communication between the
SSH client and server. It is shared by the two parties in a secure manner during SSH con-
nection setup.) In this way, the data stream gets encrypted differently every few minutes.
Thus, even if someone happened to figure out the key for a transmission, that miracle
would be valid for only a few minutes until the keys changed again.
Key Characteristics
So what exactly is a key? Essentially, a key is a large number that has special math-
ematical properties. Whether someone can break an encryption scheme depends on
their ability to find out what the key is. Thus, the larger the key is, the harder it will be
to discover it.
56
Low-grade encryption has 56 bits. This means there are 2 possible keys. To give
32 48 56
you a sense of scale, 2 is equal to 4 billion, 2 is equal to 256 trillion, and 2 is equal
to 65,536 trillion. While this seems like a significant number of possibilities, it has been
demonstrated that a loose network of PCs dedicated to iterating through every pos-
sibility could conceivably break a low-grade encryption code in less than a month. In
1998, the Electronic Frontier Foundation (EFF) published designs for a (then) $250,000
computer capable of cracking 56-bit keys in a few seconds to demonstrate the need
for higher-grade encryption. If $250,000 seems like a lot of money to you, think of the
potential for credit card fraud if someone successfully used that computer for that
purpose!
For a key to be sufficiently difficult to break, experts suggest no fewer than 128 bits.
Because every extra bit effectively doubles the number of possibilities, 128 bits offers a
genuine challenge. And if you want to really make the encryption solid, a key size of 512
bits or higher is recommended. SSH can use up to 1024 bits to encrypt your data.
The tradeoff to using higher-bit encryption is that it requires more math-processing
power for the computer to churn through and validate a key. This takes time and, there-
fore, makes the authentication process a touch slower—but most people feel this tradeoff
is worthwhile.
Cryptography References
SSH supports a variety of encryption algorithms. Public-key encryption happens to be
the most interesting method of performing encryption from site to site and is arguably
the most secure. If you want to learn more about cryptography, here are some good
books and other resources to look into:
 ? PGP by Simson Garfinkel, et al. (O’Reilly and Associates, 1994)
? Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition by
Bruce Schneier (John Wiley & Sons, 1995)
? Cryptography and Network Security: Principles and Practice, Third Edition by Wil-
liam Stallings (Prentice Hall, 2002)
? http://tools.ietf.org/id/draft-ietf-secsh-connect-25.txt
 ? www.apps.ietf.org/rfc/rfc3766.html
The PGP book is specific to the PGP program, but it also contains a hefty amount of
history and an excellent collection of general cryptography tutorials. The Applied Cryp-
tography book might be a bit overwhelming to many, especially nonprogrammers, but it
successfully explains how actual cryptographic algorithms work. (This text is considered
a bible among cypherheads.) Finally, Cryptography and Network Security is heavier on
principles than on practice, but it’s useful if you’re interested in the theoretical aspects of
cryptography rather than the code itself.
UNDERSTANDING SSH VERSIONS AND DISTRIBUTIONS
The first version of SSH that was made available by DataFellows (now F-Secure) restricted
free use of SSH to noncommercial activities; commercial activities required that licenses
be purchased. But more significant than the cost of the package is the fact that the source
code to the package is completely open. This is important to cryptographic software,
for it allows peers to examine the source code and make sure there are no holes that
may allow hackers to break the security. (In other words, serious cryptographers do not
rely on security through obscurity.) Since the U.S. government has relaxed some of its
encryption laws, work on the OpenSSH project has increased, and it is a popular alterna-
tive to some of the commercial versions of the SSH protocol.
Because the SSH protocol has become an IETF standard, there are also other devel-
opers actively working on SSH clients for other operating systems. There are many
Microsoft Windows clients, Macintosh clients, and even a Palm client, in addition to the
standard UNIX clients. You can find the version of OpenSSH that we will be discussing
at www.openssh.org.
OpenSSH and OpenBSD
The OpenSSH project is being spearheaded by the OpenBSD project. OpenBSD is a ver-
sion of the Berkeley Software Distribution (BSD) operating system (another UNIX vari-
ant) that strives for the best security of any operating system available. A quick trip to
their web site (www.openbsd.org) shows that they have gone ten years with only two
remote exploits in their default installation. Unfortunately, this level of fanaticism on
security comes at the expense of not having the most whiz-bang-feature-rich tools avail-
able, since they require that anything added to their distribution gets audited for security
first. This has made OpenBSD a popular foundation for firewalls.
The core of the OpenSSH package is considered part of the OpenBSD project and, thus,
is simple and specific to the OpenBSD operating system. To make OpenSSH available to
other operating systems, a separate group exists to make OpenSSH portable whenever
new releases come out. Typically, this happens quickly after the original release.