Pete FreitagUsing svn over ssh
Published on January 18, 2006
By Pete Freitag
By Pete Freitag
I was delighted to find that connecting to a subversion repository on a remote server over SSH was quite easy on my Mac (windows may be another story).
All you really need to do is install subversion on the remote server, the subversion install contains something called svnserve that handles all the tunneling magic for you when you connect over SSH.
Now create a repository:
svnadmin create /home/svn/test
Now install the svn client tools on your box. Now you can checkout the repository:
svn co svn+ssh://your.remote-server.com/home/svn/test
That was much easier than I thought it was going to be!
I did run into a few permission issues but its pretty easy to fix those, you just need to make sure the user your connecting with over SSH has permission to read and write to the repository.
As I said connecting with windows may be another story, because windows doesn't come with a ssh command.
Using svn over ssh was first published on January 18, 2006.
If you like reading about ssh, svn, or subversion then you might also like:
- Blocking .svn and .git Directories on Apache or IIS
- Moving a Subversion Repository to Another Server
- Ignore Files and Directories in Subversion
Discuss / Follow me on Twitter ↯
Tweet Follow @pfreitagComments
With Windows just install the free Tortoise SVN and that will give you context menus and icon overlays allowing you to perform checkouts, updates, commits and revision graphing etc. Installing Subversion without RPM, now that was the tricky bit :)
by Richard Leggett on 01/18/2006 at 10:28:20 AM UTC
Richard, I've used SVN on windows (and Tortoise SVN), but I connected to my repository over webdav, not SSH. Are you saying that Tortoise SVN has a builtin ssh client?
by Pete Freitag on 01/18/2006 at 10:38:59 AM UTC
Hi Pete, I think so, I didn't get time to set up WebDav so I'm just using svnserve. Just found this article which relates to the topic:
http://www.logemann.org/day/archives/000099.html
http://www.logemann.org/day/archives/000099.html
by Richard Leggett on 01/18/2006 at 10:55:00 AM UTC
HTTPS (via Apache2) is a better way to do secure remote access over SSH. As you've seen, SSH requires careful permission manipulation, but that's not the most troubling problem.
svnserve operates directly on the repository files (using file:/// urls), which means if you ever have two svnserve processes running at the same time, you can get contention, which usually results in a locked repository that has to be taken offline, repaired, and reenabled.
You'll run into the same issue if you combine svnserve and webdav access at the same time.
Bottom line, webdav is the best bet, since it uses a multithreaded server that can handle concurrency without corrupting your database. Apache also supports authentication with client certificates, if you're concerned about security.
svnserve operates directly on the repository files (using file:/// urls), which means if you ever have two svnserve processes running at the same time, you can get contention, which usually results in a locked repository that has to be taken offline, repaired, and reenabled.
You'll run into the same issue if you combine svnserve and webdav access at the same time.
Bottom line, webdav is the best bet, since it uses a multithreaded server that can handle concurrency without corrupting your database. Apache also supports authentication with client certificates, if you're concerned about security.
by Barney on 01/18/2006 at 11:52:32 AM UTC
Barney, I think you mean SSL not SSH.
I would have preferred connecting over Apache2 and webdav with HTTPS, but in this case I already have Apache 1.3 running, and can't use Apache 2 due to some other requirements, thus the SSH tunnel.
Luckily I don't think I will need to worry much about contention in this case since I will mainly be the only one using it for now.
I would have preferred connecting over Apache2 and webdav with HTTPS, but in this case I already have Apache 1.3 running, and can't use Apache 2 due to some other requirements, thus the SSH tunnel.
Luckily I don't think I will need to worry much about contention in this case since I will mainly be the only one using it for now.
by Pete Freitag on 01/18/2006 at 12:18:47 PM UTC
I did mean SSH, but did a horrible job wording it. "HTTPS is a better alternative than SSH" is what I should have said. I failed in my conveyance of "prefer HTTPS over SSH".
You can still run Apache2 on a non-standard port. So Apache 1.3 on :80 for your web work, and then Apache2 on :81 (or whatever) for your SVN repositories. Not that it matters a whole lot if none of the SSH downsides are relevant, but for others who might come across this post looking for insight.
You can still run Apache2 on a non-standard port. So Apache 1.3 on :80 for your web work, and then Apache2 on :81 (or whatever) for your SVN repositories. Not that it matters a whole lot if none of the SSH downsides are relevant, but for others who might come across this post looking for insight.
by Barney on 01/18/2006 at 12:47:32 PM UTC
Thanks for your insight barney.
In my case its not worth the overhead of running another server, but it might be for some.
In my case its not worth the overhead of running another server, but it might be for some.
by Pete Freitag on 01/18/2006 at 1:48:42 PM UTC
There's a slight mistake in the syntax for the ssh connection string. You need to add in your username like so:
svn co svn+ssh://[email protected]/home/svn/test
Same syntax as SSH uses. It's actually probably not a mistake because from the command line it will prompt you for the username, but if you want to use it with a tool like TortoiseSVN, you need to pass it all in at once.
Brian
svn co svn+ssh://[email protected]/home/svn/test
Same syntax as SSH uses. It's actually probably not a mistake because from the command line it will prompt you for the username, but if you want to use it with a tool like TortoiseSVN, you need to pass it all in at once.
Brian
by Brian on 01/20/2006 at 3:28:24 PM UTC
Hi Brian,
From the shell it will use your local username by default, in my case it was the same as the remote username so I omitted it. But thanks for pointing that out.
From the shell it will use your local username by default, in my case it was the same as the remote username so I omitted it. But thanks for pointing that out.
by Pete Freitag on 01/20/2006 at 3:43:07 PM UTC
I have an svn repository running on a hosted server. I would like to administrator that repository using svnadmin tool. I have the information how to ssh to the server. What i am not understanding is after establishing the ssh connection how would i use svnadmin tool. For example I want to export the whole repository to my local hard so that I can import it into a local svn server.
Any Help is appreciated.
Vivek
Any Help is appreciated.
Vivek
by Vivek on 06/23/2006 at 2:44:48 PM UTC
Hi, Pete, svn+ssh:// works fine while opensshd listen on the default port 22, but how to make svn+ssh works while changed opensshd listen on port other than 22?
svn+ssh://host:port/path dont work
svn+ssh://host:port/path dont work
by georgexsh on 09/17/2008 at 12:44:54 AM UTC
This was SO MUCH FASTER than DAV. We are talking 5 minutes vs 60 minutes for large operations. Thanks!
by Gigs on 10/05/2008 at 11:16:21 AM UTC
georgexsh, add this line to the "tunnels" section of your config file in ~/.subversion/config
ssh2222 = /usr/bin/ssh -p 2222 -l georgexsh
Instead of using "svn+ssh" you can now use "svn+ssh2222" instead (just change "2222" and "georgexsh" to your SSH port and username, respectively).
ssh2222 = /usr/bin/ssh -p 2222 -l georgexsh
Instead of using "svn+ssh" you can now use "svn+ssh2222" instead (just change "2222" and "georgexsh" to your SSH port and username, respectively).
by christefano on 12/21/2008 at 12:09:36 AM UTC
How can i restrict the access permissions of the svn clients in the following way
1. Can create new folders in the repository
2. Update the files created by themselves
3. Can not delete a delete even if they themselves created it
1. Can create new folders in the repository
2. Update the files created by themselves
3. Can not delete a delete even if they themselves created it
by faisal on 03/03/2009 at 11:31:51 PM UTC
We use svn+ssh but have a big problem with the server timing out. I thought I'd googled that the timeout problem was the apache server, but if we're using svn+ssn, apparently apache isn't used...
Why do I have a timeout problem, and is there some other way to access the repository that isn't subject to timeouts? With CVS, you could use ssh directly, and there was never a problem with timeouts.
In case you're not following what I mean with timeouts, if I do an svn diff or svn log or other command with lots of output, *and redirect (or pipe) the output*, then I (often) don't get it all. It's silently truncated.
As a work-around, I'm using script(1) and then doing the command without redirection. But that's terrible.
Why do I have a timeout problem, and is there some other way to access the repository that isn't subject to timeouts? With CVS, you could use ssh directly, and there was never a problem with timeouts.
In case you're not following what I mean with timeouts, if I do an svn diff or svn log or other command with lots of output, *and redirect (or pipe) the output*, then I (often) don't get it all. It's silently truncated.
As a work-around, I'm using script(1) and then doing the command without redirection. But that's terrible.
by cts on 10/16/2009 at 7:25:12 AM UTC
I want to know, if there is a svn co (checkout), from which user, it has been done and when?
by Jyotir on 03/03/2010 at 3:58:35 AM UTC
how can i checkout from linux server to windows through svn..
please help me..
please help me..
by Navneet on 03/05/2010 at 5:18:36 AM UTC
ok my working directory and the repository are both located on a remote server.
Can i still make use tortoise svn client on windows.I mean mounting my remote work directory and then making use svn.
Can i still make use tortoise svn client on windows.I mean mounting my remote work directory and then making use svn.
by Roger on 04/09/2010 at 3:37:25 AM UTC