From owner-svn-doc-projects@FreeBSD.ORG Tue May 21 18:37:40 2013 Return-Path: Delivered-To: svn-doc-projects@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C9C90A64; Tue, 21 May 2013 18:37:40 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 81CCB3DC; Tue, 21 May 2013 18:37:40 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r4LIbdce082087; Tue, 21 May 2013 12:37:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r4LIbd8b082084; Tue, 21 May 2013 12:37:39 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 21 May 2013 12:37:39 -0600 (MDT) From: Warren Block To: Tom Rhodes Subject: Re: svn commit: r41700 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security In-Reply-To: <201305211555.r4LFtiR8049638@svn.freebsd.org> Message-ID: References: <201305211555.r4LFtiR8049638@svn.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Tue, 21 May 2013 12:37:39 -0600 (MDT) Cc: svn-doc-projects@freebsd.org, doc-committers@freebsd.org X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 18:37:40 -0000 On Tue, 21 May 2013, Tom Rhodes wrote: > Author: trhodes > Date: Tue May 21 15:55:43 2013 > New Revision: 41700 > URL: http://svnweb.freebsd.org/changeset/doc/41700 > > Log: > Add a warning about using passphrase-less keys, > a method an admin may use to verify the passphrase > is in use on a keyfile, and how to use the "from=" > keyword to limit user specific login hosts. I'm > surprised this wasn't here before, what are we > teaching the young users of today. :P > > Modified: > projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml > > Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml > ============================================================================== > --- projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Mon May 20 14:17:49 2013 (r41699) > +++ projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Tue May 21 15:55:43 2013 (r41700) > @@ -2927,6 +2927,25 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8 > This setup allows connections to the remote machine based > upon SSH keys instead of passwords. > > + > + Many users believe that keys are secure by design and > + will use a key without a passphrase. This is > + dangerous behavior and the method > + an administrator may use to verify keys have a passphrase > + is to view the key manually. If the private key file > + contains the word ENCRYPTED the key > + owner is using a passphrase. Some commas needed, but it might be better to just break up and rearrange some of the sentences. For example: Users sometimes believe that keys are secure by design and use keys without a passphrase. This is dangerous behavior! Administrators may verify that keys have passphrases by checking the private key file. If it contains the string ENCRYPTED, a passphrase has been used. > While it may still be a weak > + passphrase, at least if the system is compromised, access > + to other sites will still require some level of password > + guessing. In addition, to better secure end users, the > + from may be placed in the public key > + file. For example, adding > + from="192.168.10.5 in the front of How about "before" instead of "in the front of"? > + ssh-rsa or rsa-dsa > + prefix will only allow that specific user to login from > + that host IP. > + "login" looks funny to me there, usually refers to a username rather than an action. > If a passphrase is used in &man.ssh-keygen.1;, the user "in" is weird. How about If a passphrase was used when with &man.ssh-keygen.1;, the user > will be prompted for the passphrase each time in order to use > the private key. &man.ssh-agent.1; can alleviate the strain > Thank you for working on this!