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://184.108.40.2060/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.
You can try it straight away but you may find an error as follows:
svn co svn+ssh://220.127.116.110/home/demo/repository/project1/trunk project1 ssh: connect to host 18.104.22.1680 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.
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:
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).
Let’s try again using the newly created project1ssh:
svn co svn+project1ssh://22.214.171.1240/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.
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!
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:
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):
Once happy, save the changes and exit out of the root access:
iptables-save > /etc/iptables.up.rules ... exit
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.