0

Trying to correctly setup subversion server in order to allow clients to access repos using all available protocols:

  • file://
  • http://
  • https://
  • svn://
  • svn+ssh://

first 3 mentioned above works correctly. I'm having some issue making coexist the last two. Earlier svn+ssh:// was working fine, normal ssh authentication. Then I've received a request to secure svn:// protocol to use SASL encryption, in case some developer want to go through it. I have implemented it, data traffic is encrypted now, but it looks like the 2 authentication methods have conflicts, because now svn:// works fine, user get asked to auth with their sasl users. But svn+ssh don't work well anymore. SSH authentication ask for the unix user authentication at the beginning, user fill it, then he get prompted with a sasl user auth, for 3 times consequently -> total: 4 authentications, result seems to fail auth also if client input correctly user and password all the times.

my configuration in $svnrepo/conf/svnserve.conf looks like this : 

[general]
realm = svnserve-auth

[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

Somebody have alredy faced this issue, or see better than me what I'm doing wrong? Thank you in advance for every hint, if im missing info please let me know

lese
  • 539
  • 1
  • 5
  • 24
  • If you're allowing `file://` access, don't even bother with setting up the rest. You've abandoned all pretenses of having any kind of security or corruption protection for your repository. There is no way to "correctly" set up Subversion in a multi-user situation with this protocol. – alroc Dec 26 '14 at 02:46
  • From what i understood until now: file:// access is enabled by default. (it works out of the box). And work only from locally -> this protocol is not usable from remote, security have nothing to do with this protocol. – lese Dec 26 '14 at 11:10
  • oh I forgot, we trust our developers , I was talking about security against external persons/attackers/men in the middle ecc. – lese Dec 26 '14 at 11:25
  • Go ahead, "trust" your developers - it only takes **one** accidental `rm` to hose your repository. I don't trust *myself* there. And you're still ignoring the fact that using `file://` in a multi-user setup is **unsupported and strongly discouraged** by the Subversion developers themselves. So please, just don't do it. Use the proper ACLs on the filesystem to require all access go through an SVN server process. – alroc Dec 26 '14 at 13:36
  • I beleave you are giving me a good hint, I will go in depth to better understand, but actually I'm missing the point. If we allow to `ssh+svn://` , developers could also rip the repos `rm -rf` by just loggin in with ssh. Me too I don't 100% trust my self, who can, mistakes happens. But backups are there for a reason. And I don't like limitations because of possibility of human errors. My question is strictly related on secure communication client-server against men-in-the-middle attacks -> encrypt data while is mooving – lese Dec 26 '14 at 13:59
  • Now you're changing your requirements. If you're concerned about MITM attacks or people reading data while it's on the wire, `file://`, `svn://` and `http://` are **all** non-starters as they're not encrypted in the first place (unless you're mounting the file share via an encrypted channel). And using exclusively HTTPS & svn+ssh *still* isn't fully protected against a MITM attack as that's going to be triggered by a *network* vulnerability, not your Subversion server/client. – alroc Dec 28 '14 at 14:58

0 Answers0