On 7/17/2011 2:07 AM, Andy Canfield wrote:
The most obvious authorization scheme is that of the host server; if
there is a user named "andy" on that server with a password "jackel"
then I would like to simply be able to talk to the subversion server as
user named "andy" password "jackel". This is how ssh and sftp work. But
apparently subversion can't handle that. True?
You can use individual accounts, the main trickiness is in making sure
that the svn repository directory is group owned, group writable and
that new files created within the repo/db tree are owned by the group
and not the individual's primary group. A quick "chmod -R g+s repo/db"
after setting up the repository takes care of that.
Our server only allowed SSH public-key authentication, so the only way
to login (other then physically at the console) is via the SSH keys. So
the "command=" line in the authorized_keys files is reasonably secure
for our purposes. Very few users actually have a way to get to the
shell. And most of those don't even know the password for their account
on the server.
(Naturally, we run backups daily, just in case someone does figure out
how to get a shell through the svnserve process and deletes a
repository. But if they can commit to the repository, there are more
nefarious things they can do there too.)
We prefix our ssh-rsa lines in the ~/.ssh/authorized_keys file with:
command="/usr/bin/svnserve -t -r /var/svn",
no-agent-forwarding,no-pty,
no-port-forwarding,no-X11-forwarding
This also has the advantage that remote URL ends being:
svn+ssh://servername/repositoryname/path/within/repo
Instead of:
svn+ssh://servername/var/svn/repositoryname/path/within/repo
With SSH ~/.ssh/config files or by setting up PuTTY sessions correctly
you can get rid of having the usernames / port numbers in the svn+ssh
URL. (We run our SSH servers on a non-standard port.)
