tags:

views:

845

answers:

4

I'm trying to understand the differences in terms of subversion repository security between a regular svn:// and svn+ssh:// access.

I've setup my subversion repository in a custom port and ip address and opened that same port on the firewall, and configured the repository with access only to authenticated users.

From what I could understand, subversion svn:// access connects through the subversion port while svn+ssh:// connects to the ssh port to create a tunnel to the server (much like using PuTTY).

I assume that the use for svn+ssh is the extra added security of not having the svn port open to the world or am I missing something else?

EDIT: How is the svn+ssh:// command different than opening a PuTTY tunnel to my server and using svn://localhost/repository instead? I've read several articles on how to get subversion to get svn+ssh to work in windows but I can't make much sense of all. Opening a tunnel with PuTTY works just fine but I do have to remember to first open it before calling svn://localhost/repository.

+8  A: 

That is right, according to the documentation what the SSH version does is to create a tunnel so instead of using the svn "socket" you would be using a more secured version using the SSH protocol to comunicate between ends.

The difference between svn+ssh:// and creating your own tunnel with PuTTY iss the convenience of the first.

Gustavo Rubio
+4  A: 

Using SSH ensures encrypted traffic so that no one can intercept your messages en route. The encryption used by SSH provides confidentiality and integrity of data over an insecure network.

gimel
+1  A: 

If I remember right svn: demands that you have a svn server running (which hangs at a socket and could be hacked). With svn+ssh: you dont need a server runninng. The client connects via normal secured and krypted ssh to the target machine and starts remote the necessary commands.

flolo
+1  A: 

[Subversion 1.5+] If you configure your svn:// correctly you force svnserve to use encryption. This requires sasl support on the server and client side.

Bert Huijben