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

[Dru Lavigne]

----- Original Message -----
> From: Benjamin Kaduk <kaduk at MIT.EDU>
> To: Dru Lavigne <dru at freebsd.org>
> Cc: doc-committers at freebsd.org; svn-doc-all at freebsd.org; svn-doc-head at freebsd.org
> Sent: Thursday, April 10, 2014 3:04 PM
> Subject: Re: svn commit: r44520 - head/en_US.ISO8859-1/books/handbook/security
> 
> 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.


Thanks! See r44530 and r44521.

Cheers,

Dru