Thursday, March 3, 2011

Differences between SVN and SVN+SSH on a Windows SVN server?

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.

From stackoverflow
  • 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.

  • 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.

  • 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.

  • [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.

0 comments:

Post a Comment