---------- Forwarded message ----------
From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Fri, Mar 15, 2013 at 12:01 AM
Subject: Re: SvnServe with Windows AD Authendication
To: Joseba Ercilla Olabarri <joseba.ercilla_at_gmail.com>
On Tue, Mar 12, 2013 at 5:55 PM, Joseba Ercilla Olabarri
<joseba.ercilla_at_gmail.com> wrote:
> On Tue, Mar 12, 2013 at 2:45 PM, Krishnamoorthi Gopal
> <krishnamoorthi_at_vernal.is> wrote:
>>
>>
>> Our management requested to upgrade this version into 7.X with AD
>> integration ( Only we need to use SVN ://)
>>
>> Is possible? ..please advise
>
>
> Actually, what you need is a SSH server for windows that supports:
> 1) Tunneling ssh sessions to local (server) svnserve command executions
> 2) Authenticating ssh session through LDAP
>
> Apparently there is a version of openSSH for windows, but don't know it's
> current state neither about what features had been ported.
> I'm currently using 1) like setup (but not on windows) working fine.
> I haven't try 2) Perhaps somebody else can contribute.
>
> Having said that, you probably have the perfect excuse to a) change the OS
> or b) add http support.
This doesn't work quite right. Unless there is only a single svn+ssh
client, or unless permissions for the repository itself are managed
very carefully to provide write access to the database and
read/execute to any hook scripts, but not write permission to anything
else, it's a security risk because every normal SSH services allow a
greate deal of open access to most of the file system. The only
Subbersion compatible way to restrict this is to use a shared single
user account, with "authorized_keys" set up to force SSH key use with
restricted operations with those keys.
These permissions are neither published, nor easily replicated, with
svnsync or similar SVN mirroring tools, so backup and configuration
replication can be an adventure.
The svn+ssh key management is a pain in the neck to set up, since I've
never seen a published tool to manage these well (comparable to the
"gitolite" tool for SSH key management through a source controlled
public SSH key repository.) But in my opinion, it should be listed
*FIRST* as the most effective svn+ssh access control, instead of last.
People tend to work their way down the list and do the simplest tsetup
they can get working, and the result is often a poor security model
for a critical source control repository.
Received on 2013-03-15 05:02:01 CET