I finally got around to setting up the svn server on my nas to use ssh last night. I’ve been meaning to do it for ages, so that I can connect up to it while I’m working at Pulse and don’t have to wait until I get home to check files in and out.
I put svn itself onto the nas years ago. It’s not supported as such, but there is a supported package installer, and it all went on with a bit of fiddling. I should have made some notes at the time, but I think the biggest problem was just working out how to make sure that only the svn user got access to the repository folders.
The instructions about svn+ssh on the qnap wiki had put me off trying to get it working before. Qnap are using a slightly hacked version of OpenSSH that only allows the admin user to log in. Any attempt to log in as another user disconnects immediately. This could be modified by changing the AllowUsers setting in /etc/ssh/sshd_config but, unfortunately, this is one of the files that the qnap overwrites automatically whenever it is booted, so changes to the setting can’t be made to stick. A lot of the instructions in the wiki are concerned with installing a full version of OpenSSH, which would be a PITA because each version of the firmware seems to need modifications to the login script to get it work correctly (and the version I have isn’t one of those listed).
As it turned out, once I looked at it more closely, only being able to login as admin wasn’t as much of a problem as it initially appeared. The obvious way to log in is to use a public key, and as it happens I already have a key pair set up that I use for other ssh logins, that was originally created using PuTTY on a PC. Although /etc/config/ssh/authorized_keys (which allows logging in using a key pair without having to specify a username/password) normally just contains a list of public keys (one per line), it can be used to run a command line when a public key is matched, and if that command line is svnserve it can also set the svn username that gets used for the session. One odd thing about using it this way is that the svnserve daemon running on the server doesn’t process the requests – it actually runs another copy.
So by putting a single line like:
command="/opt/bin/svnserve -t -r /share/svn --tunnel-user=trevor",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa ABCD76JYGJJYB65765656gjhg76576blahblahblah Trevor
into authorized_keys I can now use ssh+svn to log straight in to svn on the nas. Of course, because the linux username I have to use is admin I can’t use a keypair to log straight into the command prompt, but by not specifying a private key I can log in to the command prompt by entering a password when prompted.
There were a few things that took a bit of working out, like that the ssh session couldn’t find svnserve. It was a bit hard to work out because TortoiseSVN on the PC couldn’t really tell me what was going wrong, but I got there eventually. I also got a bit confused about the identity of the authorized_keys file at one point. The same file actually appears in several different places in the directory tree, and I was slightly surprised to find edits I made in the file under the /root folder appear in /etc.
The easiest way to set up TortoiseSVN to log in using svn+ssh is to set up a PuTTY session on the PC, and include the private key and username in its ssh settings. That way the url in Tortoise can be as simple as “svn+ssh://nas”. The final, very easy, bit was to set up the router to pass requests from a known port to the ssh port on the nas.