From users-return-5294-daniel=haxx.se@subversion.apache.org Mon Oct 11 13:48:55 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on giant.haxx.se X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id o9BBmsZ9013124 for ; Mon, 11 Oct 2010 13:48:54 +0200 Received: (qmail 10824 invoked by uid 500); 11 Oct 2010 11:48:44 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 10817 invoked by uid 99); 11 Oct 2010 11:48:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 11:48:44 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS Received-SPF: pass (nike.apache.org: domain of nkadel@gmail.com designates 209.85.160.171 as permitted sender) Received: from [209.85.160.171] (HELO mail-gy0-f171.google.com) (209.85.160.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 11:48:36 +0000 Received: by gyh20 with SMTP id 20so255910gyh.16 for ; Mon, 11 Oct 2010 04:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0sZhwjMjcYlHmCAQXzunkKJfZp368PecdTyV8mIEkhM=; b=L/NJ6XW+rt1Exu7RhNuL67tW2BRl0LB2SWSI88WW8heDm+lRfgxblHZl1vgXOGwQIH 4gX7nvxocleubUZl4EnG621VXRo+xphPztJzM8n4l6YYhSlEyK/JqIy8RJp3WQzMfDVJ gCHVTrkLMpYYvxH9THFQTTJ6Gm2tayDQiEPSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WQ2LXD7C/IRjojOaaySNcROgkaTkZJIPH1VZVfi++oFd50YOrGSt30Gt2tFgy0A+Vi qG78xgjqL4Zam0AvCB2jyoVf5utPH8tiJyxIX8xYqsuNqg6dfNUwcPetbKdn2upm2nTI CeB9zZOo+jmdyh9Y98EnXYgloy2neUGXNZQrY= MIME-Version: 1.0 Received: by 10.151.147.13 with SMTP id z13mr6434750ybn.151.1286797695481; Mon, 11 Oct 2010 04:48:15 -0700 (PDT) Received: by 10.220.128.197 with HTTP; Mon, 11 Oct 2010 04:48:15 -0700 (PDT) In-Reply-To: <4CB22169.5080203@gmail.com> References: <4CAC8E54.3090206@it-sudparis.eu> <4CADF2BB.5010106@it-sudparis.eu> <4CAED202.7090301@it-sudparis.eu> <4CAF3143.8050807@it-sudparis.eu> <4CB084FD.8020309@gmail.com> <4CB0AED1.6070703@gmail.com> <4CB22169.5080203@gmail.com> Date: Mon, 11 Oct 2010 07:48:15 -0400 Message-ID: Subject: Re: svn Farm From: Nico Kadel-Garcia To: Les Mikesell Cc: users@subversion.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Mon, 11 Oct 2010 13:48:55 +0200 (CEST) X-Friend: Nope On Sun, Oct 10, 2010 at 4:26 PM, Les Mikesell wrote= : > On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote: >>> If they didn't, it would be impossible to do automated commands. =A0The= re >>> are >>> times when you have to choose between trusting the OS to protect your >>> files >>> (which is, after all, one of its jobs) or not being able to do what you >>> want. >> >> This is incorrect. There are at least 5 tools in common use to support >> unlocking SSH keys and making them available for other programs to >> use, all based on the "ssh-agent" built-in technology of all vaguely >> complete SSH software packages. The include: >> >> * Pageant, built into the Putty installer, for Windows users. >> * gnome-keyring, already mentioned in this thread and aimed at X >> sessions, possible to use for command line sessions with considerable >> work. >> * kde-wallet, similar to gnome-keyring >> * keychain, a popular and lightweight Perl script for just this use. >> * Typing "eval ssh-agent" and "ssh-add [name of your SSH private key" >> from the command line in the window or session you will run Subversion >> from. > > All of which require user interaction at some point. =A0What if the machi= ne > reboots? =A0And what do you do about other files with contents that need = to be > protected? =A0Your ssh key probably isn't the only thing you'd like to ke= ep > private. [ We've drifted like crazy from the original subject: if this is getting boring or confusing, let me know. ] Well, yes. Your keys are *supposed* to be unavailable until re-authenticated if your system reboots, and it's in conflict with the idea that "it should work unattended no matter what" that you've just described. But then, so is having a password at all: we find ways to work around it, such as a notification email that a machine has rebooted and your keys are no longer available for your cron job automated Subversion updates tag building. There are key systems that don't normally require re-authentication, such as SSH host keys webserver SSL keys that are owned locally and owned by root. But it's not a practice used for secure web sites or critical systems such as Kerberos servers, and I've certainly done so with web servers that handled critical data, especially money and medical data. Also note that the system that holds the SSH keys, and unlocks them with a passphrase, need not be the system doing the checking out. That key holding can forward its SSH agents to connect to another host and do its work: for example, my Windows client can use Pageant and Putty to connect to a Linux server and do Subversion work with only my local client unlocking the keys. That keeps my SSH keys somewhere even safer: on my USB key, along with my svnsync m anaged copy of critical source code. If you're granting access that has to be available unattended, you've entered a problematic security environment. It's why you *absolutely should not* provide normal shell access with such an unattended key access, and you should use different keys for svn+ssh than you do for normal logins. It helps prevent people who are careless with their Subversion keys from imperiling their normal login access.