Take the 2-minute tour ×

I have an SSH server running primarily for myself but now have some code I'd like to share with my colleagues through SVN.

I am able to share it with svn+ssh by creating a separate account called 'svn', but 'svn' can also be used to log in and view my files (in /home/mine/Documents/ etc.). I tried setting the shell from bin/sh to bin/false in /etc/passwd, but this will also block users from getting my programs through svn+ssh.

Do you have any suggestions?

Thanks much! -Stephen

share|improve this question

migrated from stackoverflow.com Jul 24 '09 at 18:14

This question came from our site for professional and enthusiast programmers.

6 Answers 6

Can you not use http/https? You can just use a .htaccess/htpasswd style authentication mechanism then, rather than creating proper shell accounts.

You might be able to specify alternative authentication (using a separate password file) for svn+ssh too, but I've never done it.

share|improve this answer
Thanks for the response! Unfortunately I don't have a web server running (and seems like a lot of additional work/risk to distribute files by svn, unless there are no better alternatives for me). I should also mention that I can't seem to get svnserve to run... I think my university is blocking port 3690 :( –  Stephen Jul 24 '09 at 15:08
I don't think you have many options unfortunately. SVN+SSH requires shell access to work, which is why it fails when you set the shell to false. –  Steve Robbins Jul 24 '09 at 15:11
Yes... I was afraid of that... –  Stephen Jul 24 '09 at 15:23

If you don't want the user named "svn" to be able to view your files - that is, you only want that user to have access to anything other than the SVN repository, you just need to tweak the permissions a little bit. Do you know how to use chmod?

share|improve this answer
Thanks! Yes, do I have to chmod my entire user directory to something like 'o' minus 'r'? –  Stephen Jul 24 '09 at 15:22

You need to change the permissions on your home directory.

$ chmod 750 /home/mine
share|improve this answer

It's actually pretty simple to get exactly what you describe; the key is ssh's "forced command" option. Essentially you tell ssh that, no matter what command the client tries to execute it always executes the forced command. You set the forced command to point to a simple wrapper script that verifies the command is svnserve -t. If it is, it executes as requested. Otherwise it exits. This is the script I use:

# Verify that the requested command is an svnserve call.
# Note that sshd stores the command requested by the client in 
# the variable "SSH_ORIGINAL_COMMAND".

if [[ $SSH_ORIGINAL_COMMAND = "svnserve -t" ]]
        echo "You are only allowed svn access to this server."

There are two ways to set this forced command:

  1. If your users are logging in using key-based authentication (and they should) you can add ``command="/usr/local/sbin/validate_svn'' as the first field in their public key in ~/.ssh/authorized_keys. In order for this to be safe, though, you'll have to disable password auth. Otherwise they can log in with a password (bypassing the forced command) and edit ~/.ssh/authorized_keys to remove the restriction.
  2. Add a "Match" stanza to the end of /etc/ssh/sshd_config for the user(s) that should only be able to use svn. It should look something like this:
Match user svn
    ForceCommand /usr/local/bin/validate_svn
share|improve this answer

Thank you all for your help!! I didn't realize I only had to chmod the top level directory. I write a lot of number-crunching programs for scientific research but just getting started on revision control and code distribution (if I had any 'reputation' points I'd upvote you fo' sho'). Insyte: I am insanely delighted by your instructions for using ForceCommand - I have another sharing task (archived data for which I am not using SVN so I will try to figure out how to use for scp) for which that will be a very elegant solution! -Stephen

share|improve this answer

Thought about chrooting the SSH server and starting the subversion server inside this chrooted environment?

It may be a bit tricky to configure, but should be more secure, because nobody should be able to do anything outside this »jail« (this also prevents from privilege escalation).

share|improve this answer

Your Answer


