Date: Thu, 10 Apr 2014 15:04:06 -0400 (EDT) From: Benjamin Kaduk <kaduk@MIT.EDU> To: Dru Lavigne <dru@freebsd.org> Cc: svn-doc-head@freebsd.org, svn-doc-all@freebsd.org, doc-committers@freebsd.org Subject: Re: svn commit: r44520 - head/en_US.ISO8859-1/books/handbook/security Message-ID: <alpine.GSO.1.10.1404101449340.21026@multics.mit.edu> In-Reply-To: <201404101805.s3AI5XFJ061345@svn.freebsd.org> References: <201404101805.s3AI5XFJ061345@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1404101449340.21026>