### Switching SVN authentication from clear-text to ssh+svn ### | |
SVN is a truly awesome beast when it comes to keeping track of any software | |
development (yes, I know kids these days prefer git - probably because it's | |
more "cool" for some reason. I don't care. I use svn). | |
But to the point. SVN is an extraordinary tool, but unfortunately, it doesn't | |
come with native support for any form of encryption nor serious | |
authentication. I know two solutions to this shortcoming: | |
a) funnel all svn operations into an (SSL-enabled) apache web server, relying | |
on its webdav extension. | |
b) tunnel all svn operations through a SSH tunnel | |
I shortly investigated option a) and quickly came to the conclusion that I do | |
not like it. Too much of a mess, too much (apache) overhead, having to trust a | |
wonky http extension (webdav)... Other people may disagree - but I let them | |
have the fun with the apache/ssl/webdav contraption. | |
My choice is to go the SSH route. SSH is a perfectly standard, extremely | |
secure and very lightweight protocol. Plus, the vast majority of SVN clients | |
know how to talk svn-over-ssh. | |
How? | |
First thing - I do not want subversion to listen on a raw TCP socket any more. | |
On most Linux distributions, subversion is pre-configured through either inetd | |
or xinetd. This needs to be removed (check with 'netstat -antp' to make sure | |
it does not listen any more). | |
Then, create a system user that will accept svn queries and relay them to the | |
local 'svnserve' binary. Let's call this user "svnuser" for the sake of | |
simplicity. All (actual) svn users will need to authenticate as 'svnuser', but | |
without any rights that could allow them to fiddle with the system. This can | |
be set up through a proper authorized_keys file, as shown in the example | |
below. | |
/home/svnuser/.ssh/authorized_keys: | |
command="/usr/bin/svnserve -t -r /srv/svn --tunnel-user=mateusz",no-port-forw | |
arding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAA | |
AABIwAAAQEAykx+2hO8kBxdUAeLuL5eNgEnNWh8aWA3tkg6qPMMZWliuvrNSe7plp6RliKgmLIOVx | |
TC1OqE7B+MHWaHS/y0hOxDVwfLTtvUFd+IgmGwc4MwDOqOSohQdlaOph3Rs2b3PUrVzG73d0tztu7 | |
NVyfoZ3V13NIp1GZnptZOak910FpoiBDVMShiJr8rb4K5JIgUb6h+BRFf8pXoGIU75zEnbGlA+64l | |
3cFGBRRitzXUHGPfMtFSndyJ1MV2M6vfo2A6DYaa/YGVTBMqQTvP4am7zITO6DKjzxifLI62HP6c6 | |
9u/Q== Mateusz | |
The above line will allow me to authenticate as 'svnuser' using my ssh key, | |
and execute svnserve feeding it with a virtual user named 'mateusz'. | |
Basically, the ssh system will see 'svnuser' authenticating, while svn will | |
see 'mateusz' doing svn operations. | |
now use: | |
svn checkout svn+ssh://svnuser@svnserver/project | |
It is worth noting that all passwords declared in the svn configuration | |
(conf/passwd) become meaningless, since they won't be ever used anyway. | |
A variant of this configuration is to create separate system users for each | |
and every svn user. The principle is strictly the same, it's just more work | |
each time a new svn user needs to be added. | |