On Sun, Oct 10, 2010 at 4:26 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote:
>>> If they didn't, it would be impossible to do automated commands. There
>>> 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. What if the machine
> reboots? And what do you do about other files with contents that need to be
> protected? Your ssh key probably isn't the only thing you'd like to keep
> 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.
Received on 2010-10-11 13:48:55 CEST