BLog

ImprintImpressum
PrivacyDatenschutz
DisclaimerHaftung
Downloads 

Encrypted SVN Access via svnserve

The authors of the official SVN book Version Control with Subversion recommend in chapter 6:

If you’re trying to set up the simplest possible server for your group, a vanilla svnserve installation is the easiest, fastest route. Note, however, that your repository data will be transmitted in the clear over the network. ...

Perhaps most people read this only up to here, ending-up installing Subversion access via Apache WebDAV over HTTPS. However, let’s read it to the end:

... If your deployment is entirely within your company’s LAN or VPN, this isn’t an issue. If the repository is exposed to the wide-open Internet, you might want to make sure that either the repository’s contents aren’t sensitive (e.g., it contains only open source code), or that you go the extra mile in configuring SASL to encrypt network communications.

Ahh…, so, we could have encrypted network communications via svnserve after going only one extra mile, i.e. 1609.34 meters. Did you know that? Well actually, I found out that it isn’t even that long, perhaps about 10 extra meters to go:

My SVN-Repository is hosted on a FreeBSD 11.2 server, and let’s start by configuring, building and installing Subversion from the ports:

cd /usr/ports/devel/subversion
make config

The option SASL shall be selected, so 1 m of the extra 10 meters is done — leaving 9 meters to go.

Now build and install subversion:
make install clean
mkdir /usr/local/svn-repositories

Create the svn user and group on our system, and we would use these to restrict access to our subversion repositories:
pw useradd svn -u 369 -c "SVN user"\
               -d /usr/local/svn-repositories -s /usr/sbin/nologin

chown -R svn:svn /usr/local/svn-repositories

We need to enable svnserve in the systems startup script /etc/rc.conf:

...
# Subversion & Repositories
svnserve_enable="YES"
svnserve_flags="-d"
svnserve_data="/usr/local/svn-repositories"
...

Get a first project into the repository:

sudo -u svn svnadmin create /usr/local/svn-repositories/myproject
sudo -u svn svn import /path_to/a_local_copy_of/myproject \
     file:///usr/local/svn-repositories/myproject \
     -m "initial import"

We open the svnserve configuration file of „myproject“ using our favorite text editor, e.g. nano:

sudo -u svn nano /usr/local/svn-repositories/myproject/conf/svnserve.conf

Replace all the dummy content by:

[general]
anon-access = none
auth-access = write

# IMPORTANT for use with SASL: Choose a realm without spaces!
# If you got more, than one projects in your repository, all having
# the same access rights, then choose a generic realm for all of them.
realm = SVN

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

See above the 3 SASL specific settings, i.e. 3 extra meters, leaving 6 more extra meters for getting svnserve making use of SASL Authentication and SASL Encryption. Create the following file, using a text editor, e.g. nano ...:

sudo -u svn nano /usr/local/etc/sasl2/svn.conf

... and enter the following content, and save the file:

pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /usr/local/etc/sasl2db
mech_list: DIGEST-MD5

Now on the last extra meter, setup the SASL user & realm database, this will ask 2 times for the password for user_name:

saslpasswd2 -c -f /usr/local/etc/sasl2db -u SVN user_name
chown svn:svn /usr/local/etc/sasl2db
chmod 0400 /usr/local/etc/sasl2db

Now bring-up svnserve by restarting the system, or by using the service command:

service svnserve start

Done!

Of course, the SVN clients need to have SASL support built-into Subversion too. Anyway, this is another story.

Copyright © Dr. Rolf Jansen - 2018-07-25 08:04:05

PROMOTION