Using SSH with svnserve

In the introduction to svnserve article, we configured svnserve and secured it against unauthorised access.

However, one problem was that the connection was not encrypted. This would be fine over an Office LAN or other trusted network, but not if we are using an untrusted network such as the internet. Using the SSH protocol is the answer.

The SSH protocol will ensure a secure connection is established before checking out or committing changes to the subversion repository.

I'm going to assume you have SSH setup and configured and you are able to log into your Slice using SSH.

SSH checkout

The syntax for using SSH is very similar to the one used in the previous article. So checking out project1 using the SSH protocol would look like this:

svn co svn+ssh:// project1

The difference here is the addition of 'svn+ssh' and, in particular, note that the path to the repository is absolute. In the previous examples we didn't need the whole path.

Port error

You can try it straight away but you may find an error as follows:

svn co svn+ssh:// project1
ssh: connect to host port 22: Connection refused

The error speaks for itself - I can't access the default SSH port (port 22). The reason for this is simple: I have a custom port for my SSH access - in this case it is port 30000.

If you are using port 22 for your SSH connections (not particularly recommended) then do still read the next section as you will need to know how to add a username to the command. Just leave out defining the port number.

subversion configuration

So now a little adjustment to the local workstation's configuration files is needed so that it uses the custom SSH port.

On a Linux/unix machine it is located in:


On a windows machine it is located at:


In this example, I am using Linux on my local workstation, so I open the file like this:

nano ~/.subversion/config

As with the svnserve.conf, most is commented out and consists of instructions but the section we want is titled [tunnels].

Under the [tunnels] heading add the following line:

project1ssh = /usr/bin/ssh -p 30000 -l demo

Firstly I created a name, in this case I used 'project1ssh' as it seems easy to remember as I will use this custom connection for project1.

Then I specified the full path to the ssh binary. This is a simple security precaution so it uses the correct binary and not another one placed in your $PATH.

Lastly, I added two standard option, the first being the port to use (30000) and then the SSH user (demo).

Note that if you are using the default SSH port (22) then leave out '-p 30000'.

You can have as many of these 'tunnels' defined as you need so you can have SSH access to different machines with different repositories. Of course, you will have to be an authorised SSH user to begin with; it won't work on a random basis).

SSH checkout

Let's try again using the newly created project1ssh:

svn co svn+project1ssh:// project1

This time, the output was:

A    project1/hello.txt
A    project1/goodbye
Checked out revision 4.

Success! This logged into the Slice using SSH and securely checked out project1/trunk from the repository and placed it in the local project1 folder.


Accessing your repository using the SSH protocol does mean you can turn svnserve off and block port 3690 again (It's always good practice to block ports and stop unwanted services as soon as you can).

The reason we can turn off svnserve is that SSH creates a temporary svnserve instance.

A quick way of finding the svnserve service is to:

ps aux | grep svn

The output on my machine was:

demo     2495  0.0  0.3  45856   940 ?          Ss    20:02   0:00 svnserve -d -r repository/
demo     2501  0.0  0.2   3936    724 pts/0     S+   20:02   0:00 grep svn

Notice the id (2495) of the svnserve instance? Kill it!

kill 2495

Have a check if you like (repeat the ps aux command) but now svnserve has been killed.


Now a quick run down of how to block port 3690. Open the iptables test file:

sudo nano /etc/iptables.test.rules

Remove the lines we added to open port 3690:

# Allows svnserve connections from anywhere
-A INPUT -p tcp --dport 3690 -j ACCEPT

Temporarily give yourself root access:

sudo -i

Initiate the changes:

iptables-restore < /etc/iptables.test.rules

A quick check will show the svn port is now closed (only open ports are listed):

iptables -L

Once happy, save the changes and exit out of the root access:

iptables-save > /etc/iptables.up.rules

svnserve settings

Having gone through all of that do keep in mind that although svnserve it does still use the svnserve.conf anon-access and auth-access settings.

For example, if svnserve.conf had:

anon-access = none
auth-access = read

Then authorised SSH users would only be able to check out a repository, they would not be able to commit any changes.

The next articles will concentrate on serving multiple projects and multiple repositories from the same machine.


Article Comments:

Nicholas Orr commented Thu Sep 06 03:09:06 UTC 2007:

Nice. I'm looking forward to the next article on multiple repositories on a single host :)


Igor commented Fri Nov 09 16:20:24 UTC 2007:

Thanks! Tried to figure out how to do custom ssh port for like half an hour and then found your "svn+project1ssh" thingy.

Raphael commented Tue Nov 13 15:15:24 UTC 2007:

Great articles!

If the repository is owned by root it seems I can not commit using svn+ssh - even with the svnserve.conf having auth-access = write.

Do I just need to chown -R my repo directory to the user I will be sshing from? or perhaps add it to a group that all has write access to it?

Or is there a better way?


PickledOnion commented Tue Nov 13 15:48:43 UTC 2007:


The repository should never be owned by root.

Did you create the repo using 'sudo' or are you maybe running as the root user?

You should never run as the root user and the only time you would need to do that is the very first log in when you setup your admin user.

I hope that helps.


Raphael commented Tue Nov 13 18:33:43 UTC 2007:

Yeah I had created it with sudo.

Thanks that sheds some light.

Again, great articles.


Milan Andric commented Fri Jan 11 07:59:32 UTC 2008:

It seems the title of this article is problematic because svn+ssh seems to bypass svnserve?

'Using SSH with svnserve'

I haven't read that much about it in the svn book but it seems that I'm unable to use the svnserve auth information I configured when I use svn+ssh.

What I'm trying to do is use svnserve but through ssh as simply as possible. I know I could do an ssh tunnel in a separate step but I'm wondering if it's possible with just an svn command.

So for instance I have a unix account say, greenacres, that "hosts" the repository with an svnserve auth setup for John and Bill. John and Bill want to collaborate on that remote repository as themselves, using the svnserve auth data, not as greenacres. Is there a way to do that without doing the separate tunnel step?

PickledOnion commented Fri Jan 11 11:54:22 UTC 2008:

Hi Milan,

It doesn't bypass svnserve as such, it just activates it in a different way.

Whereas using the insecure method of connecting uses svnserve for the remote connection, this way uses SSH to connect to the Slice and then instantiates a temporary instance of svnserve.

As such, each user will need to have SSH access rights as the process, in effect, logs them into the Slice, activates svnserve, checks out/in the changes and then logs them out again.

I hope that helps to clarify the difference and the fact that svnserve is still used. Just in a different way.


Sudar commented Sat Jan 26 12:56:35 UTC 2008:

Thanks for the articles PickledOnion.

I have a windows workstation and can you please let me know how to setup the tunnel in Windows using Tortoise SVN.

I have opened the config file in the %APP_DATA% path, but I don't know what to place there. In a Unix box we can place "project1ssh = /usr/bin/ssh -p 30000 -l demo" but I need to know what we have to type in a windows machine. Thanks.

PickledOnion commented Sat Jan 26 14:20:36 UTC 2008:


Sorry but I don't know the details of how to implement the tunnel on a Windows OS.

Can I suggest a forum post? I will look into it but I don't have any form of Windows OS to work with.


Sudar commented Sat Jan 26 15:38:49 UTC 2008:

Not a problem PickledOnion, finally I figured it out myself. I am sharing it here so that it might be useful to others like me.

1) Create a new session in puTTy. In the session specify the username, private key, server ip and also port (if you have changed the default ssh port)

2) Add the following line in the [Tunnels] section of the config file present in the %APP_DATA%/subversion folder. (In my vista box this path is C:\Users\sudar\AppData\Roaming\Subversion)

slicessh = plink

3) In Tortoise SVN checkout, enter the url as svn+slicessh://puttysessionname/home/demo/repository/project1/trunk

Joe commented Tue Mar 18 11:55:45 UTC 2008:

Note: you should realise that the SSH authentication comes in place of the svnserve authentication.

So if you do: $ svn --username "itsme" co repository_url

then the username is completely ignored and user "demo" (in the example above) is used instead.

Something to be aware of!

I kept getting a "svn: Authorization failed" error which I could not explain, until I found out about this.

Kyle commented Wed Mar 19 18:02:54 UTC 2008:

If you followed "Introduction to svnserve", you should also remove the crontab entry that was added to restart svnserve at reboot:

@reboot svnserve -d -r /home/demo/repository

iptables would block anything trying to connect to port 3690, but you might as well not start a service that you won't use.

Nicos commented Wed Apr 02 12:03:49 UTC 2008:

I managed to get ssh working using RapidSVN in Windows by following this tutorial.

Florin commented Wed Apr 02 19:56:46 UTC 2008:

Does svn+ssh necessarily require the whole path to be in the URL? That is, to use your example, could I obfuscate the "/home/demo/repository" part of the path and use svn+ssh:// instead of svn+ssh://

Normally, I'd pass the -r arg in, but with SSH it looks like I have no control over that...

Andy Atkinson commented Wed Apr 09 00:09:00 UTC 2008:

+1 Kyle's comment re: removing the crontab entry. PO- you might want to add that to the article. Thanks!

David commented Mon Jun 16 18:59:29 UTC 2008:

I'm getting a "svn: Undefined tunnel scheme project1ssh" and I added this line "project1ssh = /usr/bin/ssh -p 30000 -l demo " to this file "home/demo/.subversion/config". Is there anything else I might need to do?

BTKO commented Tue Jun 24 00:08:54 UTC 2008:


I am following these create articles, and ran into a small snag. when I try to do the SSH Checkout part of the above article the connection just keeps timing out... the port is changed and all good.

Any ideas?

peter commented Tue Jul 15 15:04:26 UTC 2008:

hello i had to use "svn co svn+ssh" cos with http i had problems. the thing is i need to enter two times the password and i can't change the username to connect me... thanks Aula Virtual ssinfo Webmaster

Alan commented Wed Jul 30 01:06:58 UTC 2008:

PickledOnion, can you eloborate on your response to Milan? I want to be able to utilize multiple users in this repository. To echo Milan's comments, it doesn't seem like svnconf is utilized "normally" as it appears the passwd file is totally ignored. Assuming there isn't a quick/safe way to do that, how would I go about allowing multiple users access(besides just the user who created the repository). I've read a bit about svn groups but would love some guidance, thanks!

KFCSpike commented Thu Sep 25 15:07:08 UTC 2008:

Sudar, Thanks for the Windows tip, I couldn't have set this up without it.

One point that may help other Windows users...

If PuTTY is not in your path then the change in the config file should include the full path to plink

e.g. slicessh = C:/Program Files/PuTTY/plink

Andrew commented Tue Oct 14 12:12:01 UTC 2008: - If you want to enable 'http' access

Vince commented Wed Oct 15 03:54:25 UTC 2008:

Excellent article, extremely helpful!

Baruch commented Fri Dec 05 07:18:04 UTC 2008:

One thing I'd like to see is how to commit via remotely. When I try to replace the 'co' command with the 'commit' command, I get error messages telling me that svn://123.456.789.012 is not a working copy (it ignores the final "project1". It also says it can't open svn://123.456.789.012/.svn/entries - no such file, etc.

Baruch commented Fri Dec 05 08:00:32 UTC 2008:

WRT my previous comment - never mind. Missed it on the previous page. Maybe time for a break... commented Wed Dec 17 00:27:29 UTC 2008:

for TortoiseSVN on Windows Vista I change the config file: C:\Users\hoaitq\AppData\Roaming\Subversion\config

add the following line under [tunnels]

ssh = C:/Program Files/TortoiseSVN/bin/TortoisePlink.exe -P 12345 (note : capital P, not p)

Alex commented Wed Feb 18 13:27:54 UTC 2009:

I was also getting "svn: Undefined tunnel scheme 'project1ssh'"

Make sure you change the tunnel on your LOCAL machine, works just fine once you RTFM. Doh.

The instruction works just fine on OS X btw.

Craig commented Wed Feb 25 16:45:02 UTC 2009:

How would enabling ssh+svn work for Project Management Servers like TRAC or Redmine that connect to the repository? I imagine they would not be able to connect under those circumstances if the svnserve was turned off.

What are the security implications for leaving the svnserve service on for dumb services like that but having developers use svn with the svn+ssh configuration?

Craig commented Wed Feb 25 17:08:43 UTC 2009:

Quick answer to my own question: if the PMS is on the same slice as the svn you can just use the file:/// option and it doesn't even need an outside protocal. Sweet!

Neil commented Tue Mar 24 08:00:46 UTC 2009:

I've setup ssh to use private / public key authentication and was getting the following error when trying to run the svn checkout command

Permission denied (publickey). svn: Connection closed unexpectedly

This is because the username I login with on my slice is different to the username I login with on my workstation. To get around this I included the slice username in the svn+ssh command just before the slice ip address:

svn co svn+project1ssh://demo@ project1

Tucan commented Thu Nov 19 05:06:49 UTC 2009:

I've created the repository in /var/svn/repos, using sudo. I can check out the repository without any problems by the stated svn co svn+sshproject1... command. However, when I try to commit, then I get the error

Adding trunk/test.txt Transmitting file data .svn: Commit failed (details follow): svn: Can't open file '/var/svn/repos/db/txn-current-lock': Permission denied

Why is this and how can I fix it? Please notice that other people in addition to me will be committing to the repository, and therefore I need a method to allow access to multiple users. Thanks a lot for your help!

tom commented Fri Mar 25 13:52:34 UTC 2011:


I have configured the svn config as you suggested (tunnel = = /usr/bin/ssh -p myportnumber -l myusername)

But it won't work. When i access it, shows the following error message

svn: Undefined tunnel scheme 'tunnel'

Any idea about this? Please help me about this.

more here commented Thu Jun 06 12:38:40 UTC 2013:

I am a computer science student and the article on the introduction to sub version was very informative. I am doing my project in networking and the web site helped me a lot in completing the project. The sub version configuration is well explained. Thank you.

more here commented Thu Jun 06 12:40:51 UTC 2013:

I am a computer science student and the article on the introduction to sub version was very informative. I am doing my project in networking and the web site helped me a lot in completing the project. The sub version configuration is well explained. Thank you.

more here commented Thu Jun 06 12:41:39 UTC 2013:

I am a computer science student and the article on the introduction to sub version was very informative. I am doing my project in networking and the web site helped me a lot in completing the project. The sub version configuration is well explained. Thank you.

Want to comment?

(not made public)


(use plain text or Markdown syntax)