SH 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://123.45.67.890/home/demo/repository/project1/trunk 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://123.45.67.890/home/demo/repository/project1/trunk project1
ssh: connect to host 123.45.67.890 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:

 
/home/USERNAME/.subversion

On a windows machine it is located at:

 
%APPDATA%\Subversion

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://123.45.67.890/home/demo/repository/project1/trunk 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.

svnserve

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.

iptables

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

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.

Visits: 2