svn commit: r44520 - head/en_US.ISO8859-1/books/handbook/security

[Benjamin Kaduk]

On Thu, 10 Apr 2014, Dru Lavigne wrote:

> Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
> ==============================================================================
> --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Thu Apr 10 16:57:57 2014	(r44519)
> +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Thu Apr 10 18:05:32 2014	(r44520)
> @@ -2464,34 +2469,39 @@ racoon_enable="yes"</programlisting>
> 	<secondary>client</secondary>
>       </indexterm>
>
> -      <para>To use &man.ssh.1; to connect to a system running
> -	&man.sshd.8;, specify the username and host to log
> -	into:</para>
> +      <para>To log into a <acronym>SSH</acronym> server, use
> +	<command>ssh</command> and specify a username that exists on
> +	that server and the <acronym>IP</acronym> address or hostname
> +	of the server.  If this is the first time a connection has
> +	been made to the specified server, the user will be prompted
> +	to first verify the server's fingerprint:</para>

There are a few cases where the user will not be prompted to verify the 
server's fingerprint on the first connection (and also some where the user 
will be prompted on not-the-first connection).  They are probably uncommon 
enough that we don't need to document them, but for the record, the ones I 
can think of are:

Successful GSSAPIKeyExchange will avoid the need for a prompt

VerifyHostKeyDNS in ssh_config in combination with SSHFP records from 
DNSSEC can be configured to validate the key without prompting the user

If there is a software upgrade on either client or server such that the 
negotiated key-exchange algorithm changes (e.g., from RSA to ECDSA), the 
user will be re-prompted for the new key, even though an old key for a 
different mechanism is saved.

> +      <para>Since the fingerprint was already verified for this host,
> +	the server's key is automatically checked before prompting for
> +	the user's password.</para>
> +
> +      <para>The arguments passed to <command>scp</command> are similar to
> +	<command>cp</command>.  The file or files to copy is the first

It is probably worth noting a glaring discrepancy between scp(1) and 
cp(1)'s arguments, here, namely with respect to recursive copies.  scp 
takes -r, but cp takes -R.

> +	argument and the destination to copy to is the second.  Since the file
> +	is fetched over the network, one or more of the file
> 	arguments takes the form
> 	<option>user at host:<path_to_remote_file></option>.</para>
>
[...]
> +        <para>Instead of using passwords, a client can be configured
> +	  to connect to the remote machine
> +	  using keys instead of
> +	  passwords.  To generate <acronym>DSA</acronym> or

"instead of [using] passwords" is duplicated in this sentence.

-Ben