From owner-freebsd-security@FreeBSD.ORG Tue Aug 8 20:59:15 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FEAB16A4DE; Tue, 8 Aug 2006 20:59:15 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 138F543D45; Tue, 8 Aug 2006 20:59:14 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 9C98E2AD6880; Tue, 8 Aug 2006 20:59:12 +0000 (UTC) Received: from [69.31.99.38] (pool038.dhcp.your.org [69.31.99.38]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id E681FA0A44E; Tue, 8 Aug 2006 20:59:11 +0000 (UTC) In-Reply-To: <44D8CB3C.5090906@FreeBSD.org> References: <44D7B860.5080906@secnap.net> <44D8CB3C.5090906@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45114657-81B6-4618-BFBB-7BD2EA4D0418@dragondata.com> Content-Transfer-Encoding: 7bit From: Kevin Day Date: Tue, 8 Aug 2006 15:59:20 -0500 To: Doug Barton X-Mailer: Apple Mail (2.752.2) Cc: freebsd-security@freebsd.org Subject: Re: seeding dev/random in 5.5 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2006 20:59:15 -0000 On Aug 8, 2006, at 12:34 PM, Doug Barton wrote: >> (if doing this from an unattended bootup, expecting the 300 second >> timeout, I find that sshd does not start!) > > I cannot imagine a scenario where a competent system administrator > would do > a clean install on a machine, reboot it, and then just walk away > without > first testing to see that all expected services (especially sshd) were > working according to plan. If you can envision such a situation, > please > describe it in more detail. This actually bit us too once. We were doing an unattended diskless (PXE boot) install to 50 servers at a time. These systems were for internal use only, we didn't care at all that the key generation for sshd was done in any secure way, but it meant that we either had to manually go through each server and kickstart the random number generator so sshd would work or hack the rc scripts to do what we really wanted. We got the unattended install down to do exactly what we wanted, so there was no need really to do anything locally on each server after the install. Except this. :) This came up a second time when we had a server on another continent lose its boot drive and we needed some "remote hands" to reinstall the OS for us. We shipped a replacement drive and an install CD configured to do an unattended/automated install. The idea was to give them a replacement hot-swap drive, and a bootable CD that did an automated install. After it was done, all they had to do was remove the CD and power cycle the server. (The people on the other end weren't very technical, so we had to make this extremely easy.) They followed the instructions, and from what we could tell by having them read the text on the screen it looked like it worked. We could ping the server, but not ssh, even though we were certain we had enabled sshd in the install.cfg file. We burned another copy of the CD image and tried it on a system locally to troubleshoot. Except, that since we were watching it, we didn't let the 300 second timeout happen because we were impatient, so it worked for us. It was only after many many hours of debugging that we realized that letting the timeout happen was breaking sshd. So, there are a few reasons for wanting to be able to do an install that just works right off the bat after sysinstall that don't conflict with good sysadmin practices. Maybe sysinstall could be collecting entropy during the installation and use that for an initial seed if the timeout happens? It wouldn't be perfect, but it'd be better than killing ssh.