SSH, The Secure Shell: The Definitive Guide


Are you serious about network security? Then check out SSH, the Secure Shell, which provides key-based authentication and transparent encryption for your network connections. It's reliable, robust, and reasonably easy to use, and both free and commercial implementations are widely available for most operating systems. While it doesn't solve every privacy and security problem, SSH eliminates several of them very effectively.Everything you want to know about SSH is in our second edition of SSH, The Secure Shell: ...

See more details below
Paperback (Second Edition)
$31.13 price
(Save 30%)$44.99 List Price

Pick Up In Store

Reserve and pick up in 60 minutes at your local store

Other sellers (Paperback)
  • All (15) from $11.29   
  • New (8) from $25.51   
  • Used (7) from $11.16   
SSH, the Secure Shell: The Definitive Guide

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK 7.0
  • Samsung Galaxy Tab 4 NOOK 10.1
  • NOOK HD Tablet
  • NOOK HD+ Tablet
  • NOOK eReaders
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$19.99 price
(Save 44%)$35.99 List Price


Are you serious about network security? Then check out SSH, the Secure Shell, which provides key-based authentication and transparent encryption for your network connections. It's reliable, robust, and reasonably easy to use, and both free and commercial implementations are widely available for most operating systems. While it doesn't solve every privacy and security problem, SSH eliminates several of them very effectively.Everything you want to know about SSH is in our second edition of SSH, The Secure Shell: The Definitive Guide. This updated book thoroughly covers the latest SSH-2 protocol for system administrators and end users interested in using this increasingly popular TCP/IP-based solution.How does it work? Whenever data is sent to the network, SSH automatically encrypts it. When data reaches its intended recipient, SSH decrypts it. The result is "transparent" encryption-users can work normally, unaware that their communications are already encrypted. SSH supports secure file transfer between computers, secure remote logins, and a unique "tunneling" capability that adds encryption to otherwise insecure network applications. With SSH, users can freely navigate the Internet, and system administrators can secure their networks or perform remote administration.Written for a wide, technical audience, SSH, The Secure Shell: The Definitive Guide covers several implementations of SSH for different operating systems and computing environments. Whether you're an individual running Linux machines at home, a corporate network administrator with thousands of users, or a PC/Mac owner who just wants a secure way to telnet or transfer files between machines, our indispensable guide has you covered. It starts with simple installation and use of SSH, and works its way to in-depth case studies on large, sensitive computer networks.No matter where or how you're shipping information, SSH, The Secure Shell: The Definitive Guide will show you how to do it securely.

Read More Show Less

Product Details

  • ISBN-13: 9780596008956
  • Publisher: O'Reilly Media, Incorporated
  • Publication date: 5/15/2005
  • Edition description: Second Edition
  • Edition number: 2
  • Pages: 670
  • Sales rank: 1,004,748
  • Product dimensions: 7.08 (w) x 9.36 (h) x 1.25 (d)

Meet the Author

Daniel J. Barrett has been immersed in Internet technology since 1985. Currently working as a software engineer, Dan has also been a heavy metal singer, Unix system administrator, university lecturer, web designer, and humorist. He is the author of O'Reilly's Linux Pocket Guide, and is the coauthor of Linux Security Cookbook, and the first edition of SSH, The Secure Shell: The Definitive Guide. He also writes monthly columns for Compute! and Keyboard Magazine, and articles for the O'Reilly Network.

Richard E. Silverman has a B.A. in computer science and an M.A. in pure mathematics. Richard has worked in the fields of networking, formal methods in software development, public-key infrastructure, routing security, and Unix systems administration. He co-authored the first edition of SSH, The Secure Shell: The Definitive Guide.

Robert G. Byrnes, Ph.D., has been hacking on Unix systems for twenty years, and has been involved with security issues since the original Internet worm was launched from Cornell University, while he was a graduate student and system administrator. Currently, he's a software engineer at Curl Corporation, and has worked in the fields of networking, telecommunications, distributed computing, financial technology, and condensed matter physics.

Read More Show Less

Read an Excerpt

Chapter 8: Per-Account Server Configuration

In this chapter:
Limits of This Technique
Public Key-Based Configuration
Trusted-Host Access Control
The User rc File

We've seen two techniques for controlling the SSH server's behavior globally: compile-time configuration (Chapter 4) and serverwide configuration (Chapter 5). These techniques affect all incoming SSH connections to a given server machine. Now it's time to introduce a third, finer-grained method of server control: per-account configuration.

As the name implies, per-account configuration controls the SSH server differently for each user account on the server machine. For example, a user account sandy can accept incoming SSH connections from any machine on the Internet, while rick permits connections only from the domain, and fraidycat refuses key-based connections. Each user configures his or her own account, using the facilities highlighted in Figure 8-1, without needing special privileges or assistance from the system administrator.

We have already seen a simple type of per-account configuration. A user may place a public key into her authorization file, instructing the SSH server to permit logins to her account by public-key authentication. But per-account configuration can go further, becoming a powerful tool for access control and playing some fun tricks with your account. Accepting or rejecting connections by particular keys or hosts is just the beginning. For instance, you can make an incoming SSH connection run a program of your choice, instead of the client's choice. This is called a forced command, and we'll cover quite a few interesting applications.

Per-account configuration may control only incoming SSH connections to your account. If you're interested in configuring outgoing SSH connections by running SSH clients, refer to Chapter 7.

Limits of This Technique

Per-account configuration can do many interesting things, but it has some restrictions that we will discuss:

  • It can't defeat security measures put in place by compile-time or serverwide configuration. (Thank goodness.)
  • It is most flexible and secure if you use public-key authentication. Trusted-host and password authentication provide a much narrower range of options.

Overriding Serverwide Settings

SSH settings in a user's account may only restrict the authentication of incoming connections. They can't enable any SSH features that have been turned off more globally, and they can't permit a forbidden user or host to authenticate. For example, if your SSH server rejects all connections from the domain, you can't override this restriction within your account by per-account configuration.[1]

This limitation makes sense. No end-user tool should be able to violate a server security policy. However, end users should be (and are) allowed to restrict incoming connections to their accounts.

A few features of the server may be overridden by per-account configuration. The most notable one is the server's idle timeout, which may be extended beyond the serverwide setting. But such features can't coerce the server to accept a connection it has been globally configured to reject.

If you are an end user, and per-account configuration doesn't provide enough flexibility, you can run your own instance of the SSH server, which you may configure to your heart's content. Be cautious, though, since this is seldom the right thing to do. The restrictions you're trying to circumvent are part of the security policy defined for the machine by its administrators, and you shouldn't run a program that flouts this policy just because you can. If the machine in question is under your administrative control, simply configure the main SSH server as you wish. If not, then installing and running your own sshd might violate your usage agreement and/or certainly annoy your sysadmin. And that's never a wise thing to do.

Authentication Issues

To make the best use of per-account configuration, use public-key authentication. Password authentication is too limited, since the only way to control access is with the password itself. Trusted-host authentication permits a small amount of flexibility, but not nearly as much as public-key authentication.

If you're still stuck in the password-authentication dark ages, let this be another reason to switch to public keys. Even though passwords and public-key passphrases might seem similar (you type a secret word, and voilĂ , you're logged in), public keys are far more flexible for permitting or denying access to your account. Read on and learn how.

Public Key-Based Configuration

To set up public-key authentication in your account on an SSH server machine, you create an authorization file, typically called authorized_keys (SSH1, OpenSSH/1), authorized_keys2 (OpenSSH/2), or authorization (SSH2), and list the keys that provide access to your account. Well, we've been keeping a secret. Your authorization file can contain not only keys but also other keywords or options to control the SSH server in powerful ways. We will discuss:

  • The full format of an authorization file
  • Forced commands for limiting the set of programs that the client may invoke on the server
  • Restricting incoming connections from particular hosts
  • Setting environment variables for remote programs
  • Setting an idle timeout so clients will be forcibly disconnected if they aren't sending data
  • Disabling certain features of the incoming SSH connection, such as port forwarding and tty allocation

As we demonstrate how to modify your authorization file, remember that the file is consulted by the SSH server only at authentication time. Therefore, if you change your authorization file, only new connections will use the new information. Any existing connections are already authenticated and won't be affected by the change.

Also remember that an incoming connection request won't reach your authorization file if the SSH server rejects it for other reasons, namely, failing to satisfy the serverwide configuration. If a change to your authorization file doesn't seem to be having an effect, make sure it doesn't conflict with a (more powerful) serverwide configuration setting.

SSH1 Authorization Files

Your SSH1 authorized_keys file, generally found in ~/.ssh/authorized_keys, is a secure doorway into your account via the SSH-1 protocol. Each line of the file contains a public key and means the following: "I give permission for SSH-1 clients to access my account, in a particular way, using this key as authentication." Notice the words "in a particular way." Until now, public keys have provided unlimited access to an account. Now we'll see the rest of the story.

Each line of authorized_keys contains up to three items in order, some optional and some required:

  • A set of options (optional, surprise, surprise).
  • The public key (required). This appears in three parts:
  • The number of bits in the key, typically a small integer such as 1024
  • The exponent of the key: an integer
  • The modulus of the key: a very large integer, typically several hundred digits long
  • A descriptive comment (optional). This can be any text, such as "Bob's public key" or "My home PC using SecureCRT 3.1."

Public keys and comments are generated by ssh-keygen in .pub files, you may recall, and you typically insert them into authorized_keys by copying. Options, however, are usually typed into authorized_keys with a text editor.[2]

An option may take two forms. It may be a keyword, such as:

# SSH1, OpenSSH: Turn off port forwarding


or it may be a keyword followed by an equals sign and a value, such as:

# SSH1, OpenSSH: Set idle timeout to five minutes


Multiple options may be given together, separated by commas, with no whitespace between the options:

# SSH1, OpenSSH


If you mistakenly include whitespace:

# THIS IS ILLEGAL: whitespace between the options

no-port-forwarding, idle-timeout=5m 

your connection by this key won't work properly. If you connect with debugging turned on (ssh1 -v), you will see a "syntax error" message from the SSH server.

Many SSH users aren't aware of options or neglect to use them. This is a pity because options provide extra security and convenience. The more you know about the clients that access your account, the more options you can use to control that access.

SSH2 Authorization Files

An SSH2 authorization file, typically found in ~/.ssh2/authorization,[3] has a different format from its SSH1 ancestor. Instead of public keys, it contains keywords and values, much like other SSH configuration files we've seen. Each line of the file contains one keyword followed by its value. The most commonly used keywords are Key and Command.

Public keys are indicated using the Key keyword. Key is followed by whitespace, and then the name of a file containing a public key. Relative filenames refer to files in ~/.ssh2. For example:

# SSH2 only

Read More Show Less

Table of Contents


Chapter 1: Introduction to SSH

Chapter 2: Basic Client Use

Chapter 3: Inside SSH

Chapter 4: Installation and Compile-Time Configuration

Chapter 5: Serverwide Configuration

Chapter 6: Key Management and Agents

Chapter 7: Advanced Client Use

Chapter 8: Per-Account Server Configuration

Chapter 9: Port Forwarding and X Forwarding

Chapter 10: A Recommended Setup

Chapter 11: Case Studies

Chapter 12: Troubleshooting and FAQ

Chapter 13: Overview of Other Implementations

Chapter 14: OpenSSH for Windows

Chapter 15: OpenSSH for Macintosh

Chapter 16: Tectia for Windows

Chapter 17: SecureCRT and SecureFX for Windows

Chapter 18: PuTTY for Windows

OpenSSH 4.0 New Features

Tectia Manpage for sshregex

Tectia Module Names for Debugging

SSH-1 Features of OpenSSH and Tectia

SSH Quick Reference


Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 3 Customer Reviews
  • Anonymous

    Posted May 17, 2005

    why you should use ssh

    [A review of the 2nd EDITION 2005.] In an earlier, more trusting Internet, rlogin, ftp and telnet were widely used for remote access. But the increase in malware sniffing of these plaintext channels has led to ssh largely supplanting them. The book explains why you as a user should prefer ssh. It greatly helps to guard your account and its password. No small matter if this account has sensitive data. Actually, if you are also a sysadmin, you may want to consider restricting secure remote access to ssh. The book deals with the broad outline of the cryptographic underpinnings. But it does not require you to understand any of the formal maths. (Whew!) As a practical matter, the bulk of the text is taken up with the myriad ways that ssh implementations can be used. Shows the crucial role played by ssh. Possibly the hardest part concerns key management. Which is often the bane of any cryptosystem. So you should not regard this as a particular failing of ssh.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted August 7, 2003

    A good book overall, some minor flaws

    SSH, the Secure Shell: The Defintiive Guide is another great book from O'Reilly. As the name would suggest, however, it's not so much a meant as a tutorial or a howto as it is an in-depth analysis of SSH's workings, though the examples given could probably be used as the former. The first chapters of the book begin with a lookat what SSH is, a summary of its general uses, and the differences between the various SSH implmentations. It then quickly moves onto a number of practical examples, with explanations of both the 'how' and 'why' behind the examples. Some of the more interesting examples are those that demonstrate X11 tunnelling, key management, and how SSH can be integrated with other applications (such as PGP, for example). One of the major faults of the book is in the writing style. The regular switching back and forth between a conversational tone and a serious, technical one was something that I found rather annoying. But other than that, this is more or less a well-rounded and nicely written book on SSH, and I would certainly recommend it to anyone who is interested in this topic.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted April 25, 2002

    The definitive guide to the use of SSH

    As a System Administrator and consultant, it is difficult to find a text that covers a subject well enough to encourage others to read. This text is the most comprehensive guide to the details of the use of all variations of SSH programs in the market. My particular program of interest is OpenSSH, and this guide does a marvelous job of detailing all aspects of the application. In addition, the authors spent a considerable amount of time and energy to give the reader a clear understanding of the differences between each application. As usual, Oreilly books can get very technical, and this book is designed for people that have had the opportunity to play with SSH...even for only a brief period of time. The web is a better place if you have never used SSH before...but if you ever plan on using SSH for anything worthwhile, you better have this book on the shelf!

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 3 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)