SSH, The Secure Shell: The Definitive Guide

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many people today have multiple computer accounts. If you're a reasonably savvy user, you might have a personal account with an Internet service provider (ISP), a work account on your employer's local network, and a few computers at home. You might also have permission to use other accounts owned by family members or friends.

If you have multiple accounts, it's natural to want to make connections between them. For instance, you might want to copy files between computers over a network, log into one account remotely from another, or transmit commands to a remote computer for execution. Various programs exist for these purposes, such as ftp for file transfers, telnet for remote logins, and rsh for remote execution of commands.

Unfortunately, many of these network-related programs have a fundamental problem: they lack security. If you transmit a sensitive file via the Internet, an intruder can potentially intercept and read the data. Even worse, if you log onto another computer remotely using a program such as telnet, your username and password can be intercepted as they travel over the network. Yikes!

How can these serious problems be prevented? You can use an encryption program to scramble your data into a secret code nobody else can read. You can install a firewall, a device that shields portions of a computer network from intruders, and keep all your communications behind it. Or you can use a wide range of other solutions, alone or combined, with varying complexity and cost.

SSH, the Secure Shell, is a popular, powerful, software-based approach to network security. Whenever data is sent by a computer to the network, SSH automatically encrypts (scrambles) it. Then, when the data reaches its intended recipient, SSH automatically decrypts (unscrambles) it. The result is transparent encryption: users can work normally, unaware that their communications are safely encrypted on the network. In addition, SSH uses modern, secure encryption algorithms and is effective enough to be found within mission-critical applications at major corporations.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH, the Secure Shell, is a popular, powerful, software-based approach to network security. Whenever data is sent by a computer to the network, SSH automatically encrypts (scrambles) it. Then, when the data reaches its intended recipient, SSH automatically decrypts (unscrambles) it. The result is transparent encryption: users can work normally, unaware that their communications are safely encrypted on the network. In addition, SSH uses modern, secure encryption algorithms and is effective enough to be found within mission-critical applications at major corporations.

SSH has a client/server architecture, as shown in Figure 1-1. An SSH server program, typically installed and run by a system administrator, accepts or rejects incoming connections to its host computer. Users then run SSH client programs, typically on other computers, to make requests of the SSH server, such as "Please log me in," "Please send me a file," or "Please execute this command." All communications between clients and servers are securely encrypted and protected from modification.

Figure 1-1: SSH architecture

Our description is simplified but should give you a general idea of what SSH does. We'll go into depth later. For now, just remember that SSH clients communicate with SSH servers over encrypted network connections.

SSH software is very common today. It comes with most Linux distributions, Macintosh OS X, Sun Solaris, OpenBSD, and virtually all other Unix-inspired operating systems. Microsoft Windows has plenty of SSH clients and servers, both free and commercial. You can even find it for PalmOS, Commodore Amiga, and most other platforms. [13.3]

Many SSH clients are inspired by old Unix programs called the "r-commands:" rsh (remote shell), rlogin (remote login), and rcp (remote copy). In fact, for many purposes the SSH clients are drop-in replacements for the r-commands, so if you're still using them, switch to SSH immediately! The old r-commands are notoriously insecure, and the SSH learning curve is small.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although SSH stands for Secure Shell, it is not a true shell in the sense of the Unix Bourne shell and C shell. It is not a command interpreter, nor does it provide wildcard expansion, command history, and so forth. Rather, SSH creates a channel for running a shell on a remote computer, with end-to-end encryption between the two systems.

SSH is also not a complete security solution—but then, nothing is. It won't protect computers from active break-in attempts or denial-of-service attacks, and it won't eliminate other hazards such as viruses, Trojan horses, and coffee spills. It does, however, provide robust and user-friendly encryption and authentication.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH is a protocol, not a product. It is a specification of how to conduct secure communication over a network.

The SSH protocol covers authentication, encryption, and the integrity of data transmitted over a network, as shown in Figure 1-2. Let's define these terms:

Authentication: Reliably determines someone's identity. If you try to log into an account on a remote computer, SSH asks for digital proof of your identity. If you pass the test, you may log in; otherwise, SSH rejects the connection.
Encryption: Scrambles data so that it is unintelligible except to the intended recipients. This protects your data as it passes over the network.
Integrity: Guarantees the data traveling over the network arrives unaltered. If a third party captures and modifies your data in transit, SSH detects this fact.

Figure 1-2: Authentication, encryption, and integrity

In short, SSH makes network connections between computers, with strong guarantees that the parties on both ends of the connection are genuine. It also ensures that any data passing over these connections arrives unmodified and unread by eavesdroppers.

The first SSH product, created by Tatu Ylönen for Unix, was simply called "SSH." This caused confusion because SSH was also the name of the protocol. In this book, we use more precise terminology to refer to protocols, products, and programs, summarized in the sidebar "Terminology: SSH Protocols and Products." In short:

Protocols are denoted with dashes: SSH-1, SSH-2.
Products are denoted in mixed case, without dashes: OpenSSH, Tectia, PuTTY, etc.
Client programs are in lowercase: ssh, scp, putty, etc.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

So, what can SSH do? Let's run through some examples that demonstrate the major features of SSH, such as secure remote logins , secure file copying, and secure invocation of remote commands.

Suppose you have login accounts on several computers on the Internet. Common programs like telnet let you log into one computer from another, say, from your home PC to your web hosting provider, or from one office computer to another. Unfortunately, telnet and similar programs transmit your username and password in plain text over the Internet, where a malicious third party can intercept them. Additionally, your entire telnet session is readable by a network snooper.

Local computer ( local host, local machine): A computer on which you are logged in and, typically, running an SSH client.
Remote computer (remote host, remote machine): A second computer you connect to via your local computer. Typically, the remote computer is running an SSH server and is accessed via an SSH client. As a degenerate case, the local and remote computers can be the same machine.
Local user: A user logged into a local computer.
Remote user: A user logged into a remote computer.
Server: An SSH server program.
Server machine: A computer running an SSH server program. We sometimes simply write "server" for the server machine when the context makes clear (or irrelevant) the distinction between the running SSH server program and its host machine.
Client: An SSH client program.
Client machine: A computer running an SSH client. As with the server terminology, we simply write "client" when the context makes the meaning clear.
~ or $HOME: A user's home directory on a Unix machine, particularly when used in a file path such as ~/filename. Most shells recognize ~ as a user's home directory, with the notable exception of the Bourne shell.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH1 and the SSH-1 protocol were developed in 1995 by Tatu Ylönen, a researcher at the Helsinki University of Technology in Finland. After his university network was the victim of a password-sniffing attack earlier that year, Ylönen whipped up SSH1 for himself. When beta versions started gaining attention, however, he realized his security product could be put to wider use.

In July 1995, SSH1 was released to the public as free software with source code, permitting people to copy and use the program without cost. By the end of the year, an estimated 20,000 users in 50 countries had adopted SSH1, and Ylönen was fending off 150 email messages per day requesting support. In response, Ylönen founded SSH Communications Security Corp., (SCS, http://www.ssh.com/) in December of 1995 to maintain, commercialize, and continue development of SSH. Today he is a board member and technical advisor to the company.

Also in 1995, Ylönen documented the SSH-1 protocol as an Internet Engineering Task Force (IETF) Internet Draft, which essentially described the operation of the SSH1 software after the fact. It was a somewhat ad hoc protocol with a number of problems and limitations discovered as the software grew in popularity. These problems couldn't be fixed without losing backward compatibility, so in 1996, SCS introduced a new, major version of the protocol, SSH 2.0 or SSH-2, that incorporates new algorithms and is incompatible with SSH-1. In response, the IETF formed a working group called Secure Shell (SECSH) to standardize the protocol and guide its development in the public interest. The SECSH working group submitted the first Internet Draft for the SSH-2.0 protocol in February 1997.

In 1998, SCS released the software product SSH Secure Shell (SSH2), based on the superior SSH-2 protocol. However, SSH2 didn't replace SSH1 in the field: it was missing some features of SSH1 and had a more restrictive license, so many users felt little reason to switch, even though SSH-2 is a better and more secure protocol.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH is popular and convenient, but we certainly don't claim it is the ultimate security solution for all networks. Authentication, encryption, and network security originated long before SSH and have been incorporated into many other systems. Let's survey a few representative systems.

The Unix programs rsh, rlogin, and rcp--collectively known as the r-commands --are the direct ancestors of the SSH clients ssh, slogin, and scp. The user interfaces and visible functionality are nearly identical to their SSH counterparts, except that SSH clients are secure. The r-commands, in contrast, don't encrypt their connections and have a weak, easily subverted authentication model.

An r-command server relies on two mechanisms for security: a network naming service and the notion of "privileged" TCP ports. Upon receiving a connection from a client, the server obtains the network address of the originating host and translates it into a hostname. This hostname must be present in a configuration file on the server, typically /etc/hosts.equiv, for the server to permit access. The server also checks that the source TCP port number is in the range 1-1023, since these port numbers can be used only by the Unix superuser (or root uid). If the connection passes both checks, the server believes it is talking to a trusted program on a trusted host and logs in the client as whatever user it requests!

These two security checks are easily subverted. The translation of a network address to a hostname is done by a naming service such as Sun's Network Information Service (NIS) or the Internet Domain Name System (DNS). Most implementations and/or deployments of NIS and DNS services have security holes, presenting opportunities to trick the server into trusting a host it shouldn't. Then, a remote user can log into someone else's account on the server simply by having the same username.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH is a powerful, convenient approach to protecting communications on a computer network. Through secure authentication and encryption technologies, SSH supports secure remote logins, secure remote command execution, secure file transfers, access control, TCP/IP port forwarding, and other important features.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH is a simple idea but it has many parts, some of them complex. This chapter is designed to get you started with SSH quickly. We cover the basics of SSH's most immediately useful features:

Logging into a remote computer over a secure connection
Transferring files between computers over a secure connection

We also introduce authentication with cryptographic keys, a more secure alternative to ordinary passwords. Advanced uses of client programs, such as multiple keys, client configuration files, and TCP port forwarding, are covered in later chapters. Our examples in this chapter work with OpenSSH and Tectia on Linux and other Unix-inspired operating systems.

Suppose you're out of town on a business trip and want to access your files, which sit on a Unix machine belonging to your ISP, shell.isp.com. A friend at a nearby university agrees to let you log into her Linux account on the machine local.university.edu, and then remotely log into yours. For the remote login you could use the telnet program, but as we've seen, this connection between the machines is insecure. (No doubt some subversive college student would grab your password and turn your account into a renegade web server for pirated software and death metal MP3s.) Fortunately, both your friend's machine and your ISP's have an SSH product installed.

In the example running through the chapter, we represent the shell prompt of the local machine, local.university.edu, as a dollar sign ($) and the prompt on shell.isp.com as shell.isp.com>.

Suppose your remote username on shell.isp.com is pat. To connect to your remote account from your friend's account on local.university.edu, you type:

    $ ssh -l pat shell.isp.com
    pat's password: ******
    Last login: Mon Aug 16 19:32:51 2004 from quondam.nefertiti.org
    You have new mail.
    shell.isp.com>

This leads to the situation shown in Figure 2-1. The ssh command runs a client that contacts the SSH server on shell.isp.com

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Suppose you're out of town on a business trip and want to access your files, which sit on a Unix machine belonging to your ISP, shell.isp.com. A friend at a nearby university agrees to let you log into her Linux account on the machine local.university.edu, and then remotely log into yours. For the remote login you could use the telnet program, but as we've seen, this connection between the machines is insecure. (No doubt some subversive college student would grab your password and turn your account into a renegade web server for pirated software and death metal MP3s.) Fortunately, both your friend's machine and your ISP's have an SSH product installed.

In the example running through the chapter, we represent the shell prompt of the local machine, local.university.edu, as a dollar sign ($) and the prompt on shell.isp.com as shell.isp.com>.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Suppose your remote username on shell.isp.com is pat. To connect to your remote account from your friend's account on local.university.edu, you type:

    $ ssh -l pat shell.isp.com
    pat's password: ******
    Last login: Mon Aug 16 19:32:51 2004 from quondam.nefertiti.org
    You have new mail.
    shell.isp.com>

This leads to the situation shown in Figure 2-1. The ssh command runs a client that contacts the SSH server on shell.isp.com over the Internet, asking to be logged into the remote account with username pat. You can also provide user@host syntax instead of the -l option to accomplish the same thing:

    $ ssh pat@shell.isp.com

Figure 2-1: Our example scenario

On first contact, SSH establishes a secure channel between the client and the server so that all transmissions between them are encrypted. The client then prompts for your password, which it supplies to the server over the secure channel. The server authenticates you by checking that the password is correct and permits the login. All subsequent client/server exchanges are protected by that secure channel, including everything you type into the SSH application and everything it displays to you from shell.isp.com.

It's important to remember that the secure channel exists only between the SSH client and server machines. After logging into shell.isp.com via ssh, if you then telnet or ftp to a third machine, insecure.isp.com, the connection between shell.isp.com and insecure.isp.com is not secure. However, you can run another ssh client from shell.isp.com to insecure.isp.com, creating another secure channel, which keeps the chain of connections secure.

We've covered only the simplest use of ssh. Chapter 7 goes into far greater depth about its many features and options.

Continuing the story, suppose that while browsing your files, you encounter a PDF file you'd like to print. In order to send the file to a local printer at the university, you must first transfer the file to

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The preceding example session provided a quick introduction to the most often-used client programs--ssh and scp--in a format to follow while sitting at your computer. Now that you have the basics, let's continue the example but include situations and complications glossed over the first time. These include the "known hosts" security feature and the SSH escape character.

If you're following at the computer as you read, your SSH clients might behave unexpectedly or differently from ours. As you will see throughout the book, SSH implementations are highly customizable, by both yourself and the system administrator, on either side of the secure connection. Although this chapter describes common behaviors of SSH programs based on their installation defaults, your system might be set up differently.

If commands don't work as you expect, try adding the -v ("verbose") command-line option, for example:

    $ ssh -v shell.isp.com

This causes the client to print lots of information about its progress, often revealing the source of the discrepancy.

The first time an SSH client encounters a new remote machine, it may report that it's never seen the machine before, printing a message like the following:

    $ ssh -l pat shell.isp.com
    The authenticity of host 'shell.isp.com (192.168.0.2)' can't be established.
    RSA key fingerprint is 77:a5:69:81:9b:eb:40:76:7b:13:04:a9:6c:f4:9c:5d.
    Are you sure you want to continue connecting (yes/no)?

Assuming you respond yes (the most common response), the client continues:

    Warning: Permanently added 'shell.isp.com,192.168.0.2' (RSA) to the list of known hosts
               .

This message appears only the first time you contact a particular remote host. The message is a security feature related to SSH's concept of known hosts.

Suppose an adversary wants to obtain your password. He knows you are using SSH, and so he can't monitor your connection by eavesdropping on the network. Instead, he subverts the naming service used by your local host so that the name of your intended remote host,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In our running example, the user pat is authenticated by the SSH server via login password. Passwords, however, have serious drawbacks:

In order for a password to be secure, it should be long and random, but such passwords are hard to memorize.
A password sent across the network, even protected by an SSH secure channel, can be captured when it arrives on the remote host if that host has been compromised.
Most operating systems support only a single password per account. For shared accounts (e.g., a superuser account), this presents difficulties:
- Password changes are inconvenient because the new password must be communicated to all people with access to the account.
- Tracking usage of the account becomes difficult because the operating system doesn't distinguish between the different users of the account.

To address these problems, SSH supports public-key authentication: instead of relying on the password scheme of the host operating system, SSH may use cryptographic keys . [3.2.2] Keys are more secure than passwords in general and address all the weaknesses mentioned earlier.

A key is a digital identity. It's a unique string of binary data that means "This is me, honestly, I swear." And with a little cryptographic magic, your SSH client can prove to a server that its key is genuine, and you are really you.

An SSH identity uses a pair of keys, one private and one public. The private key is a closely guarded secret only you have. Your SSH clients use it to prove your identity to servers. The public key is, like the name says, public. You place it freely into your accounts on SSH server machines. During authentication, the SSH client and server have a little conversation about your private and public key. If they match (according to a cryptographic test), your identity is proven, and authentication succeeds.

The following sequence demonstrates the conversation between client and server. [3.4.2.4] (It occurs behind the scenes, so you don't need to memorize it or anything; we just thought you might be interested.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Each time you run ssh or scp with public-key authentication, you have to retype your passphrase. The first few times you might not mind, but eventually this retyping gets annoying. Wouldn't it be nicer to identify yourself just once and have ssh and scp remember your identity until further notice (for example, until you log out), not prompting for your passphrase? In fact, this is just what an SSH agent does for you.

An agent is a program that keeps private keys in memory and provides authentication services to SSH clients. If you preload an agent with private keys at the beginning of a login session, your SSH clients won't prompt for passphrases. Instead, they communicate with the agent as needed. The effects of the agent last until you terminate the agent, usually just before logging out. The agent program for both OpenSSH and Tectia is called ssh-agent.

Generally, you run a single ssh-agent in your local login session, before running any SSH clients. You can run the agent by hand, but people usually edit their login files (for example, ~/.login or ~/.xsession) to run the agent automatically. SSH clients communicate with the agent via a local socket or named pipe whose filename is stored in an environment variable, so all clients (and all other processes) within your login session have access to the agent. [6.3.4] To try the agent, type:

    $ ssh-agent $SHELL

where SHELL is the environment variable containing the name of your login shell. Alternatively, you could supply the name of any other shell, such as sh, bash, csh, tcsh, or ksh. The agent runs and then invokes the given shell as a child process. The visual effect is simply that another shell prompt appears, but this shell has access to the agent.

Once the agent is running, it's time to load private keys into it using the ssh-add program. By default, ssh-add loads the key from your default identity file:

    $ ssh-add
    Enter passphrase for /home/you/.ssh/id_dsa:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

One of the most frequently asked questions about SSH is: "How can I connect to a remote machine without having to type a password or passphrase?" As you've seen, an SSH agent can make this possible, but there are other methods as well, each with different trade-offs. Here we list the available methods with pointers to the sections discussing each one.

To use SSH clients for interactive sessions without a password or passphrase, you have several options:

Public-key authentication with an agent [2.5] [6.3]
Hostbased authentication [3.4.3.6]
Kerberos authentication [11.4]

Another way to achieve passwordless logins is to use an unencrypted private key with no passphrase. Although this technique can be appropriate for automation purposes, never do this for interactive use. Instead, use the SSH agent, which provides the same benefits with much greater security. Don't use unencrypted keys for interactive SSH!

On the other hand, noninteractive, unattended programs such as cron jobs or batch scripts may also benefit from not having a password or passphrase. In this case, the different techniques raise some complex issues, and we discuss their relative merits and security issues later. [11.1]

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Several other clients are included in addition to ssh and scp :

sftp , an ftp-like client
slogin, a link to ssh, analogous to the rlogin program

The scp command is convenient and useful, but many users are already familiar with FTP (File Transfer Protocol), a more widely used technique for transferring files on the Internet. sftp is a separate file-transfer tool layered on top of SSH. The OpenSSH sftp can run over either SSH-1 or SSH-2, whereas the Tectia version runs over SSH-2 only due to implementation details.

sftp has several advantages:

It is secure, using an SSH-protected channel for data transfer.
Multiple commands for file copying and manipulation can be invoked within a single sftp session, whereas scp opens a new session each time it is invoked.
It can be scripted using the familiar ftp command language.
In other software applications that run an FTP client in the background, you can try substituting sftp, thus securing the file transfers of that application. You might need to run an agent, however, since programs that normally invoke ftp might not recognize the sftp passphrase prompt, or they might expect you to have suppressed FTP's password prompt (using a .netrc file, for example).

Anyone familiar with FTP will feel right at home with sftp, but sftp has some additional features of note:

Command-line editing using GNU Emacs-like keystrokes (Control-B for backward character, Control-E for end of line, and so forth).
Wildcards for matching filenames. OpenSSH uses the same "globbing" syntax that is supported by most common shells, while Tectia uses an extended regular expression syntax described in Appendix B.
Several useful command-line options:

-b filename (OpenSSH)
-B filename (Tectia): Read commands from the given file instead of the terminal.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

From the user's point of view, SSH consists of several client programs and some configuration files. The most commonly used clients are ssh for remote login, and scp and sftp for file transfer. Authentication to the remote host can be accomplished using existing login passwords or with public-key cryptographic techniques. Passwords are more immediately and easily used, but public-key authentication is more flexible and secure. The ssh-keygen, ssh-agent, and ssh-add programs generate and manage SSH keys.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH secures your data while it passes over a network, but how exactly does it work? In this chapter, we move firmly onto technical ground and explain the inner workings of SSH. Let's roll up our sleeves and dive into the bits and bytes.

This chapter is written for system administrators, network administrators, and security professionals. Our goal is to teach you enough about SSH to make an intelligent, technically sound decision about using it. Mostly, we deal with SSH-2 as the current and recommended SSH protocol; our treatment of the old and deprecated SSH-1 is limited to a summary of its differences and limitations. When we refer to "the SSH protocol," we mean SSH-2.

Of course, the ultimate references on SSH are the protocol standards and the source code of an implementation. We don't completely analyze the protocols or recapitulate every step taken by the software. Rather, we summarize them to provide a solid, technical overview of their operation. If you need more specifics, you should refer to the standards documents. The SSH Version 2 protocol is in draft status on the IETF standards track; it is available at:

The older SSH-1 protocol is called Version 1.5 and is documented in a file named RFC included in the source package of the now-obsolete SSH1.

The major features and guarantees of the SSH protocol are:

Privacy of your data, via strong encryption
Integrity of communications, guaranteeing they haven't been altered
Authentication, i.e., proof of identity of senders and receivers
Authorization, i.e., access control to accounts
Forwarding or tunneling to encrypt other TCP/IP-based sessions

Privacy means protecting data from disclosure. Typical computer networks don't guarantee privacy ; anyone with access to the network hardware, or to hosts connected to the network, may be able to read (or sniff) all data passing over the network. Although modern switched networks have reduced this problem in local area networks, it is still a serious issue; passwords are easily stolen by such sniffing attacks.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The major features and guarantees of the SSH protocol are:

Privacy of your data, via strong encryption
Integrity of communications, guaranteeing they haven't been altered
Authentication, i.e., proof of identity of senders and receivers
Authorization, i.e., access control to accounts
Forwarding or tunneling to encrypt other TCP/IP-based sessions

Privacy means protecting data from disclosure. Typical computer networks don't guarantee privacy ; anyone with access to the network hardware, or to hosts connected to the network, may be able to read (or sniff) all data passing over the network. Although modern switched networks have reduced this problem in local area networks, it is still a serious issue; passwords are easily stolen by such sniffing attacks.

SSH provides privacy by encrypting data that passes over the network. This end-to-end encryption is based on random keys that are securely negotiated for that session and then destroyed when the session is over. SSH supports a variety of encryption algorithms for session data, including such standard ciphers as AES, ARCFOUR, Blowfish, Twofish, IDEA, DES, and triple-DES (3DES).

Integrity means assuring that data transmitted from one end of a network connection arrives unaltered on the other end. The underlying transport of SSH, TCP/IP, does have integrity checking to detect alteration due to network problems (electrical noise, lost packets due to excessive traffic, etc.). Nevertheless, these methods are ineffective against deliberate tampering and can be fooled by a clever attacker. Even though SSH encrypts the data stream so that an attacker can't easily change selected parts to achieve a specific result, TCP/IP's integrity checking alone can't prevent, say, an attacker's deliberate injection of garbage into your session.

A more complex example is a replay attack. Imagine that Attila the Attacker is monitoring your SSH session and also simultaneously watching over your shoulder (either physically, or by monitoring your keystrokes at your terminal). In the course of your work, Attila sees you type the command

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We've covered the basic properties of SSH. Now we focus on cryptography, introducing important terms and ideas regarding the technology in general. There are many good references on cryptographic theory and practice, and we make no attempt here to be comprehensive. (For more detailed information, check out Bruce Schneier's excellent book, Applied Cryptography, published by John Wiley & Sons.) We introduce encryption and decryption, plaintext and ciphertext, keys, secret-key and public-key cryptography, and hash functions, both in general and as they apply to SSH.

Encryption is the process of scrambling data so that it can't be read by unauthorized parties. An encryption algorithm (or cipher) is a particular method of performing the scrambling; examples of currently popular encryption algorithms are RSA, AES, DSA, and Blowfish. The original, readable data is called the plaintext , or data "in the clear," while the encrypted version is called the corresponding ciphertext.

The goal of an encryption algorithm is to convert plaintext to ciphertext. To do this, you pass two inputs to the encryption algorithm: the plaintext itself, and a key, a string that is typically a secret known only to you. From these inputs, the algorithm produces the ciphertext. An encryption algorithm is considered secure if it is infeasible for anyone to read (or decrypt) the encrypted ciphertext without the key. An attempt to decrypt data without its key is called cryptanalysis.

It's important to understand the word "infeasible" in the previous paragraph. Today's most popular and secure ciphers are vulnerable to brute-force attacks: if you try every possible key, you eventually succeed in decryption. However, when the number of possible keys is large, a brute-force search requires a great deal of time and computing power. Based on the state of the art in computer hardware and algorithms, it is possible to pick sufficiently large key sizes to render brute-force key-search unreasonable for your adversary. What counts as infeasible, though, depending on how valuable the data is, how long it must stay secure, and how motivated and well-funded your adversary is. Keeping something secret from your rival startup for a few days is one thing; keeping it secret from a major world government for 10 years is quite another.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

SSH has about a dozen distinct, interacting components that produce the features we've covered. [3.1] Figure 3-1 illustrates the major components and their relationships to one another.

Figure 3-1: SSH architecture

By "component" we don't necessarily mean "program": SSH also has keys, sessions, and other fun things. In this section we provide a brief overview of all the components, so you can begin to get the big picture of SSH:

Server

A program that allows incoming SSH connections to a machine, handling authentication, authorization, and so forth. In most Unix SSH implementations, the server is sshd.

Client

A program that connects to SSH servers and makes requests, such as "log me in" or "copy this file." In OpenSSH and Tectia, the major clients are ssh, scp, and sftp.

Session

An ongoing connection between a client and a server. It begins after the client successfully authenticates to a server and ends when the connection terminates. Sessions may be interactive or batch.

Key

A relatively small amount of data, generally from tens of to 1,000 or 2,000 bits, used as a parameter to cryptographic algorithms such as encryption or message authentication. The key binds the algorithm operation in some way to the key holder: in encryption, it ensures that only someone else holding that key (or a related one) can decrypt the message; in authentication, it allows you to verify later that the key holder actually signed the message. There are two kinds of keys : symmetric or secret key, and asymmetric or public key. [3.2.2] An asymmetric key has two parts: the public and private components. SSH has several types of keys, as summarized in Table 3-1.

Table 3-1: Keys, keys, keys
Name	Lifetime	Created by	Type	Purpose
User key	Persistent	User	Public	Identify a user to the server

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The SSH protocol has two major, incompatible versions, called Version 1 and Version 2. [1.5] We refer to these as SSH-1 and SSH-2. The SSH-1 protocol is now a relic; it is less flexible than SSH-2, has unfixable security weaknesses, and has been deprecated for years. Its implementations see no real development aside from bug fixes, and the default protocol for most SSH software has been SSH-2 for some time now. In this chapter, as we describe "the SSH protocol," we are talking about SSH-2. We limit our treatment of SSH-1 to a summary of its design, its differences with SSH-2, and its weaknesses.

The SSH protocol is actually divided into four major pieces, formally described as four separate protocols in different IETF documents, and in principle independent of one another. In practice, they are layered together to provide the set of services most users associate with SSH as a whole. These are:

SSH Transport Layer Protocol (SSH-TRANS)
SSH Authentication Protocol (SSH-AUTH)
SSH Connection Protocol (SSH-CONN)
SSH File Transfer Protocol (SSH-SFTP)

There are other documents that describe other aspects of, or extensions to, the protocols, but the preceding ones represent the core of SSH. As of this writing, these documents are still "Internet-Drafts," but after much effort by the IETF SECSH working group, they have been submitted to the IESG for consideration as proposed standards and may soon be published as Internet RFCs.

Figure 3-2 outlines the division of labor between these protocols, and how they relate to each other, application programs, and the network. Elements in italics are protocol extensions defined in separate Internet-Draft documents, which have attained fairly widespread use.

Figure 3-2: SSH-2 protocol family

SSH is designed to be modular and extensible. All of the core protocols define abstract services they provide and requirements they must meet, but allow multiple mechanisms for doing so, as well as a way of easily adding new mechanisms. All the critical parameters of an SSH connection are negotiable, including the methods and algorithms used in:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

With a solid understanding of the current SSH protocol behind us, we now quickly summarize SSH-1 in terms of its differences, weaknesses, and shortcomings in comparison with SSH-2:

Non-modular: SSH-1 is defined as a single monolithic protocol, rather than the modular approach taken with the SSH-2 suite.
Less negotiation: SSH-1 has more fixed parameters; in fact, only the bulk cipher is negotiated. The integrity algorithm, host key type, key-exchange methods, etc., are all fixed.
Ad hoc naming: SSH-1 lacks the well-defined naming syntax for SSH-2 entities which allows for smooth, implementation-specific extensions.
Single authentication: SSH-1's user authentication process allows only one method to succeed; the server can't require multiple methods.
RhostsRSA authentication: SSH-1's RhostsRSA authentication, analogous to hostbased, is in principle limited to using a network address as the client host identifier. This limits its usefulness in the face of network issues such as NAT, proxying, mobile clients, etc.
Less flexible remote forwarding: SSH-1 remote forwarding specifies only a port, not a full socket, so can't be bound to different addresses on multihomed servers, and the gatewayhosts option must be set globally for all remote forwardings rather than per port.
Weaker integrity checking: SSH-1 uses a weak integrity check, the CRC-32 algorithm. CRC-32 is not cryptographically strong, and its weakness is the basis of the Futoransky/Kargieman "insertion attack"; see http://seclists.org/lists/firewall-wizards/1998/Jun/0095.html.
Server keys: The fixed key exchange of SSH-1 employs an extra asymmetric key called the server key, not to be confused with a host key. [3.6.1] The server key is an ephemeral public/private key pair, regenerated once per hour and used to provide forward secrecy for the session key. Forward secrecy means that even if long-term secrets such as user or host private keys are compromised later, these can't be used to decrypt SSH sessions recorded earlier; the use of an extra key which is never written to disk assures this. The Diffie-Hellman algorithm which is the basis of all the SSH-2 key exchanges provides forward secrecy by itself, and so an extra "server key" is not needed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are many differences among the current crop of SSH implementations: features that aren't dictated by the protocols, but are simply inclusions or omissions by the software authors. Here we discuss a few implementation-dependent features of various products:

Host keys
Authorization in hostbased authentication
SSH-1 backward compatibility
Randomness
Privilege separation

SSH host keys are long-term asymmetric keys that distinguish and identify hosts running SSH, or instances of the SSH server, depending on the SSH implementation. This happens in two places in the SSH protocol:

Server authentication verifying the server host's identity to connecting clients. This process occurs for every SSH connection.
Authentication of a client host to the server; used only during RhostsRSA or hostbased user authentication.

Unfortunately, the term "host key" is confusing. It implies that only one such key may belong to a given host. This is true for client authentication but not for server authentication, because multiple SSH servers may run on a single machine, each with a different identifying key. This so-called "host key" actually identifies a running instance of the SSH server program, not a machine.

OpenSSH maintains a single database serving both server authentication and client authentication. It is the union of the system's known_hosts file (/etc/ssh/ssh_known_hosts), together with the user's ~/.ssh/known_hosts file on either the source machine (for server authentication) or the target machine (for client authentication). The database maps a hostname or address to a set of keys acceptable for authenticating a host with that name or address. One name may be associated with multiple keys (more on this shortly).

Tectia, on the other hand, maintains two separate maps for these purposes:

The hostkeys map for authentication of the server host by the client
The knownhosts

Table of Contents