SSH, The Secure Shell: The Definitive Guide
by Daniel J. Barrett & Richard E. Silverman


Unconfirmed error reports are from readers. They have not yet been approved 
or disproved by the author or editor and represent solely the opinion of 
the reader.

If you have any error reports or technical questions, you can send them to
booktech@oreilly.com. (Please specify the printing date of your copy.)


This page was last updated May 09, 2006.


Here's a key to the markup:

        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification


UNCONFIRMED errors and comments from readers:


(xii)  2nd from top line;
In First Edition - [5/01] printing:

"and servers. serverwide configuration..."

should read

"and servers, serverwide configuration..."


(xiii)  3rd line from bottom;
In First Edition - [5/01] printing:

"labled K."

should read

"labeled K."


[28]  2nd paragraph;
I believe the text 

"The OpenSSH version of ssh-keygen also can produce either RSA or DSA keys, 
defaulting to RSA. Its operation is similar to ssh-keygen1."

does not adequately explain how to generate OpenSSH keys and therefore succeed 
with OpenSSH public key authentication. In fact the entire tract dealing with 
OpenSSH authentication by cryptographic key seems too short and inaccurate. 
Newer versions of OpenSSH default to protocol 2, and the default key format is 
RSA. They seem to be looking for this file in the client:

~/.ssh/id_rsa (the private key)
and
~/.ssh/id_rsa.pub (the public key)

which you generate with the command 

ssh-keygen -t rsa

You then copy the contents of ~/.ssh/id_rsa.pub to the ~/.ssh/authorized_keys2 
file on the remote account that you wish to log in to. 

Make sure the file permissions are set to -rw------- on the id_rsa file.  Check 
file permissions for other files as well.

You then log out of the client
re-login to the client
log out of the server account
and finally try to run ssh -v -l accountname server.example.com

OpenSSH public key authentication should succeed at this point.


(43)  last paragraph;
Change "should it be distinguish" to
       "should it be able to distinguish"


(75)  bullet list;
In the bullet list at the top of the page (and the bottom of the
preceeding page) there are 6 items.  The last two are "stronger
integrity checking ..." and "periodic replacement of the session
key".  For each of these items, there is a section giving details
in the next several pages.  There is, however, an extra section
on page 78 (3.5.1.6 in my copy) between the two sections on integrity
checking and session rekeying.  This talks about Hostbased authenti-
cation, a topic which does not appear on the bullet list.  This is
hardly a big deal, but maybe in the interests of completeness there
should be an additional bulleted item about hostbased authentication
on the list on page 75.


{82}  third paragraph, fourth sentence;
Text reads:  "The following example shows the public keys for one SSH server running
on wynken, port 22, and two running on blynken, ports 22 and 220."

The example actually shows one SSH server running on blynken and two running on
wynken.


(84)  first sentence, fifth paragraph;
Text reads:  "Since ssh-signer2 is a relatively small and simple, ..."

Should read:  "Since ssh-signer2 is relatively small and simple, ..."

or

"Since ssh-signer2 is a realatively small and simple program, ..."


(88)  paragraph 5;
Shouldn't the sentence

"If existing FTP implementations could easily be made to operate
over SSH, there would be no need for ssh, ...."

read
"... there would be no need for scp, ..."

Surely the ability of FTP to do something doesn't influence the need
for ssh in a more general context, even it it does have a bearing on
the file transfer situation.  At the very least, this is confusing
wording.


{96}  I believe there is an error on page 96 of the SSH, the Secure Shell 
book, printing date February 2001. In section 3.9.2.3, the description of the 
action of 3DES says the algorithm encrypts plaintext with three iterations 
of the DES algorithm, using three separate keys. In truth, only two keys 
are used -- the first key is used twice, during the first and third iterations.


(153)  5.4.2.2, example:

cf. the box on p. 155 and p. 363:
Umask 022
sould read
Umask 0022



(155)
Editing /etc/services:
Line reads 
"ssh         tcp/22" 
should read 
"ssh        22/tcp"



[178,179]  Second paragraph on 178 and Second paragraph on 179:

On 178 the indication is that only SSH1 & SSH2 support the '@host' construct
for AllowUsers.

On 179, the wildcard example uses the '@' construct and is labeled as being
valid for SSH1, SSH2, OpenSSH.

These cannot both be true - either OpenSSH supports host-address
restrictions or it does not, regardless of wildcards.

I believe that p178 is correct, and OpenSSH does NOT support hostnames in
the sshd config file.

OpenSSH does support host restrictions in the individuals authorised_keys
file, using the "from=the.host.name" construct.


[179]  mid-page;
Section 5.5.2.1 addresses Account access control, specifically use of AllowUsers and
DenyUsers.  On page 179 at mid-page, the examples go from using AllowUsers to
AllowHosts with the sytax for AllowUsers and then back to using AllowUsers at the
bottom of the page.  AllowHosts and DenyHosts is not discussed until Section 5.5.2.3.
All examples on page 179 should read AllowUsers.


(179)  Last line of code before last paragraph;
Line reads:  "AllowUsers "*@10.1.1.[:isdigit:]##"


Should read:  "AllowUsers "*@10.1.1.[:digit:]##"


(183)  Last line before bulleted list;
The title of the bulleted list reads:  "As for AllowHosts and DenyHosts:".

However, the bulleted list for AllowHosts and DenyHosts is on the middle of page 182.

This line should read "As for AllowShosts and DenySHosts".  This is perfectly clear
from the last bullet point which is on page 184.


(182)  second line of second paragraph of 5.5.2.3;
sentence reads:


... access by s host more concisely, getting rid of the unnecessary account-name ...

probably mean, "... access by a host ..."?


[213]  1st paragraph:

The end of the sentence should be corrected to "... your public
key file:"

Losing one's private key file is in my opinion a major problem...


(215)  In last sentence of #3;
Last sentence of number three reads:  "Therefore, keys are a quick and convenient
method for checking that a key is unaltered."

Should read:  "Therefore, fingerprints are a quick and . . ."


[229] On the 2001-02 printing, in the first shell fragment on the
page, a pretty major error.

I'm no Bourne shell expert, but it seems to me that the fragment

	test -n "SSH_AUTH_SOCK" && exec ssh-agent $SHELL

is busted; if the agent's not running, the variable's empty, hence the
test failes, so the exec doesn't get fired off!  At any rate, I wasn't
able to get this to work as printed, so, after a side-trip to
``Learning the Bash Shell'' I ended up using:

	if [ -n "$SSH_AUTH_SOCK" ]
	then
		echo "ssh-agent already running, PID $SSH_AGENT_PID"
	else
		echo "starting ssh-agent..."
		exec ssh-agent $SHELL
	fi
	

{233}  -N description;
On p233, you describe how to use -N, and on the next page, you warn people not to.
The warning should at least be on the same page, if not referenced directly in the
description of -N usage.
	
	
	
(241)  Figure 7-1;
In the right-hand column ("Files" for the SSH server), there are some typos. 
The word "environment" is misspelled as "enviroment" (twice) and near the 
bottom you see "/~.k5login" which should be "~/.k5login".


{282}  The example for the -v command-line option at the bottom of the page 
looks like it isn't available for SSH2:

	# SSH1, OpenSSH

SSH2 is missing because of the following output ("SSH Version 1.2.27") but it 
might be misleading.


(300)  8.2.4.1, 2nd sentence:

... at least as secure a ...
should read
... at least as secure as a ...


(311)  First sentence on page;
First sentence reads:  "Timeouts are set in with the idle-timeout option."

Should remove the word 'in' so the sentence reads:  "Timeouts are set with the idle-
timeout option."


(330)  first sentence of last paragraph;
First sentence reads:  "In addition to any physical network interfaces it may have, a
host running IP has also has a virtual one called, the loopback interface."


One of the "has" words should be deleted.


(341)  Third sentence of second paragraph;
Sentence reads:  "You log into one of these machines using SSH, and want to run an
graphical performance-monitoring tool,"

Should read:  "... and want to run a graphical ..."


{344}  Figure 9-10 X forwarding:

Currently, the dotted circle on the left is labelled "X client"
and the dotted circle on the right "X server".

The labels should be the other way around, "X server" on the left
and "X client" on the right.


{361}  --without-rsh:

The book says "... or at runtime in the server-wide configuration file."
This is not correct as there is no sshd option for this. This belongs to the
client specific configuration, cf. p. 125 (4.1.5.12) and p. 269.


(390)  3rd full para;
Last sentence: /decisions based on the their contents
should be
/decisions based on their contents/


(392)  Note (footprints);
s/port -orwarding/port forwarding/


{406}  fourth typed code (constant width) example;
the third constant width code example cites the -q argument to ssh (for
supressed output), while the fourth expands it to -w, a non-existent option.


[461]  nowhere in chapter;

This isn't really a technical mistake,
but I think future editions of the book should make
mention of Kermit-95 2.X, certainly a major implimentation
of SSH,  in the chapter summarizing various instantiations
of SSH.  Details at
http://www.kermit-project.org/http://www.columbia.edu/kermit


{509}  keyword Macs:

keyword Macs should be MAC (according to p. 165)


{509}  keyword IgnoreRootRhosts:

p. 169 says the meaning of the keyword IgnoreRootRhosts is to ignore /.rhosts 
and /.shosts and not just "Ignore /.rhosts files"


{509}  keyword IgnoreUserKnownHosts:

keyword IgnoreUserKnownHosts is valid for OpenSSH only (according to p. 171)


{512}  keyword Host;

keyword Host does not mark the beginning of a section for SSH2; for SSH2 it defines a host's real name (cf. 244 + 248)


{512}  keyword FallBackToRsh:

keyword FallBackToRsh applies to SSH2 as well (according to p. 269)


{514}  keyword PGPSecretKeyFile:

keyword PGPSecretKeyFile is not a ssh keyword (cf. p. 172)


{514}  keyword UseRsh:

keyword UseRsh applies to SSH2 as well (according to p. 269)


{515}  option -g:
option -g applies to SSH1 and OpenSSH only (according to p. 323) 


{519}  Environment Variables:

SSH2_ORIGINAL_COMMAND is missing under environment variables (see p. 304)