SVN account sharing
From A2Wiki
DISCLAIMER: These directions are not supported by A2 Hosting. If there are incorrect or missing steps, please update the wiki page as needed.
Contents |
SVN Account Sharing
Account owner creates a repository
cd ~ mkdir repos svnadmin create --fs-type fsfs repos/project1
Please note that the actual project path within the repository is important to understand for a later step!
Account owner generates SSH RSA keys on the server
This gives the owner SSH keys to use in the future if needed, as well as setting up the ~/.ssh directory properly.
[owner@www ~]# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/owner/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/owner/.ssh/id_rsa. Your public key has been saved in /home/owner/.ssh/id_rsa.pub. The key fingerprint is: 30:66:35:29:8f:9f:d6:df:ce:6a:ee:bd:7f:0a:8c:38 owner@ownersdomain.com
Developers generate keys
Each developer generates SSH RSA public and private keys. Make sure to leave the passphrase empty, or else the passphrase will have to be entered with each SSH access.
How to generate RSA keys depends on the OS. On Linux, for example:
[user1@dev1 ~]$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/user1/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user1/.ssh/id_rsa. Your public key has been saved in /home/user1/.ssh/id_rsa.pub. The key fingerprint is: bd:d4:6b:d6:97:09:14:8e:ea:ec:23:0a:f3:b4:ee:e3 user1@dev1.example.com
The developer then gets the public key to the account owner (perhaps via email, IM, etc.). Because it's a public key, there's no harm in distributing it "insecurely." Line breaks in all SSH keys in this howto are broken for readability. In real life, they should remain as one long line!
[user1@dev1 ~]$ cat .ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAx6jDPi1TpygtCzu7rZbmsl97wJLc6Uadp bSo+JPxZ3/abreSef29+WG+GSTTiMag8q7HqRH0yLc3RqGKOiCOaSNPNHWAzdtEQxikfc GIb+JsHrFr/L+2gt5rDHnTFwBmErPAWQV82WaCgcMqVavPlqKr6/ecMU1060+gxl/6jSt g5Oy6fA4R3b6CtPe2Ol8cltMroQuzi1cCjJoUlOpuo7TUmQOxPfITyigTJjeYJGuBZgc5 cTMV7XFbVjpoBn8a7+IYfpg3cS+HEvolyqgHTQ7MtPef86yKMLrUPM0yiv57gaR8EvSt1 a4brQZHIYWqSZUkKZ6/bdrUoJ/rKP29eQ== user1@dev1
Account owner edits ~/.ssh/authorized_keys on the server and inserts the developer's public key on a blank line, and saves the file. At this point, user1 should be able to connect via SSH on port 7822 as the account owner without using a password. Note that the first time each user connects from a particular computer, they will get a prompt:
[user1@dev1 ~]$ ssh -p7822 -l owner ownersdomain.com The authenticity of host 'ownersdomain.com (192.168.1.2)' can't be established. RSA key fingerprint is 01:60:ba:ef:12:39:14:67:f3:32:44:da:2c:0c:0b:1a. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'ownersdomain.com,192.168.1.2' (RSA) to the list of known hosts. Last login: Thu Aug 30 14:11:01 2007 from dsl.yourisp.net owner@ownersdomain.com [~]#
Remove shell access for developers
The developers probably should not have full shell access to the server. So we will lock their keys down to only be able to do SVN tunneling, as well as identify who they are to SVN (so all commits don't come from the account owner's name).
Account owner edits ~/.ssh/authorized_keys and changes the key entries for each user to look like this (should all be one long line for each key; broken here for readability purposes only):
command="/usr/bin/svnserve -t -r /home/owner/repos --tunnel-user=user1", no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAx6jDPi1TpygtCzu7rZbmsl97wJLc6Uadp bSo+JPxZ3/abreSef29+WG+GSTTiMag8q7HqRH0yLc3RqGKOiCOaSNPNHWAzdtEQxikfc GIb+JsHrFr/L+2gt5rDHnTFwBmErPAWQV82WaCgcMqVavPlqKr6/ecMU1060+gxl/6jSt g5Oy6fA4R3b6CtPe2Ol8cltMroQuzi1cCjJoUlOpuo7TUmQOxPfITyigTJjeYJGuBZgc5 cTMV7XFbVjpoBn8a7+IYfpg3cS+HEvolyqgHTQ7MtPef86yKMLrUPM0yiv57gaR8EvSt1 a4brQZHIYWqSZUkKZ6/bdrUoJ/rKP29eQ== user1@dev1
The "command" section in front of the key spawns an svnserve process for the user when they connect via SSH, locks it into /home/owner/repos (where the repository is), and tunnels their svn username "user1". The no-* entries are to keep them from getting a shell or doing other mischievous things. Change /home/owner/repos to match your own username and repository location, of course.
For example, if your repository is just /home/owner/repos and not /home/owner/repos/project1, the "-r /path" section should be "-r /home/owner", and the "/repos" part will be passed in from the client-side connection command.
Executing SVN commands
At this point, users whose keys are in authorized_keys can check out the project, etc. There should be an SVN_SSH environment variable set to tell svn how to connect to the remote server.
On Linux, do
export SVN_SSH="ssh -p7822"
Add the above to the developer's .bashrc file on their workstation; every time they log in, it will be set.
[user1@dev1 ~]$ svn list svn+ssh://owner@ownersdomain.com/project1 [user1@dev1 ~]$
No files are added yet. Let's check out the project and add a file:
[user1@dev1 ~]$ svn co svn+ssh://owner@ownersdomain.com/project1 ~/working Checked out revision 0. [user1@dev1 ~]$ cd ~/working [user1@dev1 working]$ ls [user1@dev1 working]$ touch file1 [user1@dev1 working]$ svn add file1 A file1 [user1@dev1 working]$ svn commit -m "added file 1" Adding file1 Transmitting file data . Committed revision 1. [user1@dev1 working]$ svn list svn+ssh://owner@ownersdomain.com/project1 file1 [user1@dev1 working]$ svn update At revision 1. [user1@dev1 working]$ svn log ------------------------------------------------------------------------ r1 | user1 | 2007-09-05 17:14:45 -0400 (Wed, 05 Sep 2007) | 1 line added file 1 ------------------------------------------------------------------------
