BUY THIS BOOK

Safari Books Online

What is this?

Looking to Reprint this content?

Envelope Tell a friend

SSH, The Secure Shell: The Definitive Guide
SSH, The Secure Shell: The Definitive Guide

By Daniel J. Barrett, Richard E. Silverman

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Introduction to SSH
Content preview·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 one or more PCs 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 and rcp for file transfers, telnet and rlogin 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. 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 it. 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!
What Is SSH?
Content preview·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 it. 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.
An SSH-based product might include clients, servers, or both. Unix products generally contain both clients and servers; those on other platforms are usually just clients, though Windows-based servers are beginning to appear.
If you're a Unix user, think of SSH as a secure form of the Unix r-commands: rsh (remote shell), rlogin (remote login), and rcp (remote copy). In fact, the original SSH for Unix includes the similarly named commands ssh, scp, and slogin as secure, drop-in replacements for the r-commands. Yes, you can finally get rid of those insecure .rhosts and hosts.equiv files! (Though SSH can work with them as well, if you like.) If you're still using the r-commands, switch to SSH immediately: the learning curve is small, and security is far better.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
What SSH Is Not
Content preview·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, in the manner of the Unix rsh command, but with end-to-end encryption between the local and remote computer.
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!
The SSH Protocol
Content preview·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 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.
SSH-based products—i.e., products that implement the SSH protocol—exist for many flavors of Unix, Windows, Macintosh, and other operating systems. Both freely distributable and commercial products are available. [Section 13.3]
The first SSH product, created by Tatu Ylönen for Unix, was simply called "SSH." This causes confusion because SSH is also the name of the protocol. Some people call Ylönen's software "Unix SSH," but other Unix-based implementations are now available so the name is unsatisfactory. In this book, we use more precise terminology to refer to protocols, products, and programs, summarized in Sidebar "Terminology: SSH Protocols and Products", In short:
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Overview of SSH Features
Content preview·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. We use SSH1 in the examples, but all are possible with OpenSSH, SSH2, and F-Secure SSH.
Suppose you have accounts on several computers on the Internet. Typically, you connect from a home PC to your ISP, and then use a telnet program to log into your accounts on other computers. Unfortunately, telnet transmits your username and password in plaintext 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 contact from your local computer. Typically, the remote computer is running an SSH server and is contacted 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 will 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.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
History of SSH
Content preview·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 that 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, Ltd., (SCS, http://www.ssh.com/) in December of 1995 to maintain, commercialize, and continue development of SSH. Today he is chairman and chief technology officer of 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 SECSH (Secure Shell) 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, for two reasons. First, SSH2 was missing a number of useful, practical features and configuration options of SSH1. Second, SSH2 had a more restrictive license. The original SSH1 had been freely available from Ylönen and the Helsinki University of Technology. Newer versions of SSH1 from SCS were still freely available for most uses, even in commercial settings, as long as the software was not directly sold for profit or offered as a service to customers. SSH2, on the other hand, was a commercial product, allowing gratis use only for qualifying educational and non-profit entities. As a result, when SSH2 first appeared, most existing SSH1 users saw few advantages to SSH2 and continued to use SSH1. As of this writing, three years after the introduction of the SSH-2 protocol, SSH-1 is still the most widely deployed version on the Internet, 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!
Related Technologies
Content preview·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 SSH1 clients ssh, slogin, and scp. The user interfaces and visible functionality are nearly identical to their SSH1 counterparts, except that SSH1 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.
Likewise, blind trust in privileged TCP ports represents a serious security risk. A cracker who gains root privilege on a trusted machine can simply run a tailored version of the
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Summary
Content preview·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!
Chapter 2: Basic Client Use
Content preview·Buy reprint rights for this chapter
SSH is a simple idea, but it has many complex parts. 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, will be covered in later chapters.
We use SSH1 and SSH2 (and occasionally OpenSSH) for all examples. If the syntax differs among the products, we'll discuss each of them.
Suppose you're out of town on a business trip and want to read your email, which sits on a Unix machine belonging to your ISP, shell.isp.com. A friend at a nearby university agrees to let you log into her Unix account on the machine local.university.edu, and then remotely log into yours. For the remote login you could use the telnet or rlogin programs, 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 Ani DiFranco MP3s.) Fortunately, both your friend's Unix 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 May 24 19:32:51 1999 from quondam.nefertiti.org
You have new mail.
shell.isp.com>
This leads to the situation shown in Figure 2-1. The
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
A Running Example
Content preview·Buy reprint rights for this chapter
Suppose you're out of town on a business trip and want to read your email, which sits on a Unix machine belonging to your ISP, shell.isp.com. A friend at a nearby university agrees to let you log into her Unix account on the machine local.university.edu, and then remotely log into yours. For the remote login you could use the telnet or rlogin programs, 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 Ani DiFranco MP3s.) Fortunately, both your friend's Unix 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!
Remote Terminal Sessions with ssh
Content preview·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 May 24 19:32:51 1999 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 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 the contents of the email you proceed to read using a mail program on 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 reading your email, you encounter a message with an attached 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!
Adding Complexity to the Example
Content preview·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 does some extra work and prints a message like the following:
$ ssh -l pat shell.isp.com
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?
Assuming you respond yes (the most common response), the client continues:
Host 'shell.isp.com' added 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, shell.isp.com, translates falsely to the IP address of a computer run by him! He then installs an altered SSH server on the phony remote host and waits. When you log in via your trusty SSH client, the altered SSH server records your password for the adversary's later use (or misuse, more likely). The bogus server can then disconnect with a preplanned error message such as "System down for maintenance—please try again after 4:00 p.m." Even worse, it can fool you completely by using your password to log into the real
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Authentication by Cryptographic Key
Content preview·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. [Section 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.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
The SSH Agent
Content preview·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 SSH1, SSH2, and OpenSSH 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 the process environment, so all clients (and all other processes) within your login session have access to the agent. 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
Need passphrase for /u/you/.ssh/identity ('Your Name <you@local.org>').
Enter passphrase: ************
Identity added: /u/you/.ssh/identity ('Your Name <you@local.org>').
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Connecting Without a Password or Passphrase
Content preview·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 tradeoffs. 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 [Section 2.5] [Section 6.3]
  • Trusted-host authentication [Section 3.4.2.3]
  • Kerberos authentication [Section 11.4]
Another way to achieve password-less 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 will discuss their relative merits and security issues later. [Section 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!
Miscellaneous Clients
Content preview·Buy reprint rights for this chapter
Several other clients are included in addition to ssh and scp :
  • sftp, an ftp-like client for SSH2
  • slogin, a link to ssh, analogous to the rlogin program
  • Hostname links to ssh
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. It was developed by SSH Communications Security and was originally available only in SSH2, but other implementations have since appeared (e.g., client support in SecureFX and server support in OpenSSH). sftp is available only in SSH2: it is implemented as an SSH2 subsystem [Section 5.7] and thus not readily adaptable to use with SSH1.
sftp is advantageous for several reasons:
  • 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 may need an agent when trying this or similar FTP replacements, since programs that use FTP might not recognize the prompt sftp issues for your passphrase, 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
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Summary
Content preview·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 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!
Chapter 3: Inside SSH
Content preview·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. We cover the SSH-1 and SSH-2 protocols separately since they have important differences.
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:
http://www.ipsec.com/tech/archive/secsh.html
http://www.ietf.org/
The older protocol implemented in SSH1 and OpenSSH/1 is Version 1.5 and is documented in a file named RFC included in the SSH1 source package.
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
  • 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
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Overview of Features
Content preview·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 regularly 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 de

Return to SSH, The Secure Shell: The Definitive Guide