---------- Forwarded message ---------- From: Nico Kadel-Garcia <nka...@gmail.com> Date: Fri, Mar 15, 2013 at 12:01 AM Subject: Re: SvnServe with Windows AD Authendication To: Joseba Ercilla Olabarri <joseba.erci...@gmail.com>
On Tue, Mar 12, 2013 at 5:55 PM, Joseba Ercilla Olabarri <joseba.erci...@gmail.com> wrote: > On Tue, Mar 12, 2013 at 2:45 PM, Krishnamoorthi Gopal > <krishnamoor...@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.
