On Tue, Sep 1, 2009 at 10:14 AM, <kmradke_at_rockwellcollins.com> wrote:
>
> Nico Kadel-Garcia <nkadel_at_gmail.com> wrote on 08/31/2009 06:57:30 PM:
>> 2009/8/31 David Weintraub <qazwart_at_gmail.com>:
>> > Subversion doesn't have its own native security. This is actually a
>> > better
>> > way because it allows you to use external security regimens.
>> >
>> > For example, we use LDAP and connect to our Active Server via Apache.
>> > Now, I
>> > don't have to worry about settiing up users independently. If a user is
>> > in
>> > the Windows server's engineering group, they automatically have access
>> > to
>> > Subversion without me doing anything. Once they leave, they have no more
>> > access.
>> >
>> > Even better, their Subversion password is the same as their Windows
>> > password. No more forgetting their password.
>> >
>> > If I use ssh+svn://, the operating system handles logging in and out. My
>> > name and password is the same as my Unix account.
>>
>> What? No-no-no-no-no. This is used by some, but the far safer and more
>> useful way to do is to designate an svn user, who's
>> $HOME/.ssh/authorized_keys file This relies on SSH keys, not
>> passwords, which allows single-sign-on style user access by having an
>> ssh-agent (or a Gnome or KDE "wallet", which is out of band of
>> Subversion's key storage).
>
>> No user passwords. None. Nyet. Nil. Nein. Nada. A user selected
>> password is normally used to unlock the relevant SSH key, and a Gnome
>> or KDE wallet can manage that. And this way, the repository URL's look
>> ile 'svn+ssh://svn@reposerver/var/lib/svn/repository', or a similar
>> structure. This allows user login to that server to be quite distinct
>> and even unnecessary. This is the approach that Sourceforge uses, for
>> example. The public SSH key in is set to designate the relevant
>> Subversion user based on which key is used. It's a very handy
>> approach, and avoids the security issues that I tend to rant about, at
>> the cost of some setup time.
>
> This setup is a pain for both the user and the administrator. Additional
> steps must be performed by each before work can begin.
> (And ssh keys are really no better than a password, you are just
> forcing the user to have different piece of secret information.)
>
> Why not use something like kerberos? Windows will transparently
> checkout a ticket. No password needed and no additional setup needed
> by either the user or the administrator for new users. Granted, this
> only works well in a corporate environment, but it is a very big win
> when dealing with less technical users...
>
> The beauty of Subversion is that it lets YOU choose the
> appropriate authentication method for your environment.
I'd love to have it Kerberos-based! But there are fascinating requirements.
* Kerberos and possibly LDAP management of the Subversion as a
distinct privilege from shell login, to prevent the need for system
shell accounts on the Subversion server. This is fundamental: the
ordinary Subversion repository user *should not* have shell access to
the server in a secure environment, and most definitely should not
have user-based write privileges to the repository directories to
avoid file ownership whackiness of file-based access. The places I've
been consulting lately, for family travel reasons, all have their own
Active Directory services which I had little input for, but I took
advantage of their Kerberos user authentication. But this approach
could buy much better tools for managing the service privileges
necessary for Subversion. It takes some work.
* Support for the necessary Kerberos utilities on all the requisite
clients. That's a pretty serious demand on client toolsuites: it's
theoretically feasible for TortoiseSVN, as a well-defined and
well-managed toolkit, but getting it into more odd basic OS's is not
so easy. And as soon as you allow access *without* the necessary
Kerberos utilities, for example by un-Kerberos-based SSH, you're
screwed by the plain-text password storage problem, and you may as
well throw out all that Kerberos work because many users will simply
have no incentive to use it. And even Putty doesn't have full Kerberos
support, and that of many "stable", popular production grade operating
systems like RHEL 4 is years out of date and therefore rather limited.
* If you're using Kerberos based ssh+svn, where do you inject the
settings to set the 'user' based on their particular login key or
other settings? This works well with the SSH public keys because the
public keys set the 'user' for Subversion logging, even though they're
all coming in through the same centrally managed account. But that's
the sort of thing that Kerberos/LDAP integration would be great for,
and that's a lot of work I don't personally have the expertise or time
to do. If you do, *FABULOUS*. I'd welcome and support your work.
* A major difficulty there is that most Kerberos authentication
systems allow password authentication at connect time, rather than
insisting on the previous local storage of a Kerberos ticket. As soon
as you have that, I think you run headlong into *exactly* what I was
most concerned about: the storage of user passwords in
$HOME/.svn/auth/.
* Have you ever tried to teach a newbie (possibly quite talented, but
nevertheless a newbie) to configure customized Kerberos setups? I
have. It wasn't pretty.
Kerberos is amazing and cool stuff: I was very lucky to meet some of
its original authors and catch presentations on how it works at MIT
and Harvard, and I'd *love* to see it well-integrated into Subversion.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2391501
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-06 16:47:58 CEST