We didn't bother trying to tie in Windows Authentication with our
system. (Windows XP clients against a Linux SVN server.)
Instead, we went with simple public/private keys. Where the keys are
stored on the user's laptops and may or may not be protected with a
passphrase. Because of this unknown, we limit what that pub/priv key
pair can do on the SVN server (running Linux and OpenSSH). (Using the:
command="svnserve -t" at the start of the key line in the user's
It's moderately risky that someone could swipe their private key file
and impersonate them. But that would only allow them the ability to
send commands to "svnserve -t" and any damage could be repaired easily.
You may want to EFS encrypt the private key file so that only the
user's login profile can be used to decrypt it. Which is slightly more
secure then storing the private key without a password on the local drive.
For ease of use, we setup a batch file that automatically loads the
private key into Pageant at startup (when the user logs in). If they
protected their private key with a passphrase, they get prompted as soon
as they login. After that, the key is cached in Pageant and there are
no other obstacles to accessing the SVN repositories.
To create the key in PuTTYGen (part of PuTTY):
0. Fire up PuTTYGen to create the pub/priv key file
1. Choose key type "SSH2 RSA", set key size to 2048 bits
2. Click "Generate", move the mouse over the dialog
3. Change the key comment to: username@subversion
4. Enter a passphrase to protect the key (or you can leave this empty as
this key pair can only be used for SubVersion).
5. Click on "Save Public Key", put the key somewhere safe, give it a
file extension of ".pub"
6. Click on "Save Private Key", put the key in the same location as the
.pub file (the file extension will be .ppk)
7. Send the public key (.pub) file to the SVN admin via e-mail,
indicating that it is your SubVersion user key. I will append:
command="svnserve -t" to the front of it so that it can only be used for
SubVersion. This key will then be added to your ~/.ssh/authorized_keys
file on the svn server.
Note: PuTTYGen actually spits out an OpenSSH compatible public key
format in the dialog that you can have your users copy-n-paste into that
e-mail to the SVN admin. However... if you forget, you can import a
PuTTY format public-key file into OpenSSH.
Note #2: By default, PuTTYGen saves the .pub file out in a unix format,
which causes issues trying to copy-n-paste it into a SecureCRT window.
You may want to transfer the file up using FTP/SCP which does line
ending translation. Or convert the file to an MS-DOS line ending using
To get the file up on the server using copy-n-paste and SecureCRT (or
maybe even PuTTY):
$ cd /home/username
$ su username
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ cat > firstname.lastname@example.org
$ ssh-keygen -i -f email@example.com >> authorized_keys
$ vi authorized_keys
Note #3: If you had grabbed the OpenSSH compatible information from the
PuTTYGen dialog, you could've just opened up the user's authorized_keys
file in vi and pasted that information in. Otherwise, you have to use
the ssh-keygen command to convert PuTTY's key format into something that
Append the following to the front of the ssh key line that you just
added (the last line in the authorized_keys file):
Which limits what command can be run when the user authenticates against
the SSH server using that particular pub/priv key pair. (See your
OpenSSH documentation for details.)
Lastly, make sure the file inside the user's .ssh folder are owned by
them (if you "su username" from the root account and were already
impersonanting them, you'll only have to worry about the chmod values).
$ cd /home/username/.ssh
$ chmod 600 *
$ chown username *
Repository URLs now look like:
If you want to setup the command-line client to work alongside of
TortoiseSVN, you can easily accomplish that as well. There are 2
environment variables that must be configured in order for the command
line tools to work:
1. Right-click on My Computer, Properties, Advanced, Environment Variables
2. Under System Variables, click "New"
3. Variable name: SVN_ASP_DOT_NET_HACK
4. Variable value (can be anything at all): _svn
5. Under System Variables, highlight "PATH" and click "Edit"
6. Add ";C:\Program Files\PuTTY" to the end of the PATH statement
(which assumes you installed PuTTY to that location)
7. Under User Variables, click "New"
8. Variable name: SVN_SSH
9. plink -ssh -l user -pw password
- "user" should be your username on the SVN server (i.e. "chad" or
- the "-pw password" is optional if you did not put a passphrase on your key
10. Open up a command prompt window
11. Go to a local working copy (C:\Erdos\Webs) and run the "svn update"
You can now use the SVN command line tools against the local working
copy. This typically means "CD"ing to the local working copy folder and
running commands like:
C:> svn info
C:> svn status
C:> svn update
Note that the SVN commands are recursive and will traverse sub-projects
in the repository and working copy.
Another note: We currently use a no-password public/private key pair
along with a special user account on the SVN server (limited to only
running "svnserve -t" to send our web server log files to a central
repository for safe keeping. Each web server has a separate account
(with it's own pub/priv key pair) and each web server writes to their
own repository. Because of the compression/delta methods used by SVN,
we can run this hourly with very little traffic overhead.
SET SVN_SSH=plink -ssh -l sys-machine
REM FTP surveys
svn add *
(rinse repeat for other log folders)
svn ci -m "Updated log files (automatic hourly commit)"
FYI: The first line in that batch file that calls Pageant can also be
used as a startup script file to load keys into Pageant when the user
logs in to their workstation.
(And now we get into things that I haven't completely tried out yet.)
One issue with putting the username@ into the SVN URL is a case where
you have 2 developers time-sharing a PC on different shifts/days. In
addition, you may be limited where the working copy absolute pathnames
need to be identical across all developer machines (i.e. the working
copy is always C:\Work\Project\ due to limitations of Windows-centric
What is possible is that you set the SVN_SSH environment variable to be
different on a user-by-user basis (maybe set it in their Active
Directory profile). For example:
SET SVN_SSH=plink -ssh -l username
Then you may be able to access the repository as only:
Which may allow 2 developers to share a local working copy seamlessly by
logging in under their own names. So long as the private key file is
loaded into Pageant, things should work just fine.
I haven't gotten around to trying that out yet, but I'll have to
implement something of the sort when I get to a particular machine that
is time-shared across 2 shifts.
I think that's all the little tidbits of tricks that we've learned over
the past few months. SSH based access was definitely the easiest to
configure and we went with repository-level permissions (multiple
repositories with different /etc/group ownership for each repository and
then assigning users to belong to the proper group).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Nov 27 21:28:48 2006