Bringing Git to QNAP TS-210

There are two (quite obvious) ways, how you can use Git on your QNAP TS-210 (or any other QNAP).

If you only want to be able to update local repositories (i.e. use QNAP as Git client) then this article is for you and all you need to do is to install Git on QNAP and generate proper SSH keys.

If, on the other hand, you would like to store on QNAP repositories, that other uses (i.e. use QNAP as Git server), then you need to search the Internet for some alternative solution, sorry.

Install Git on QNAP

You can install Git on your QNAP directly from your console or by using App Center.

First method seems better, because it will (should) install you newest version of Git and all required dependencies, while App Center package may be a little bit out-dated.

On the other hand, command line method requires you to have IPKG / Optware installed on your QNAP (installing this package is the first thing, you should do after installing QNAP itself; if you don’t have it, you should install it ASAP).

And, in certain situations, it may be safer (in the meaning, that App Center’s apps are always checked for compatibility with QNAP software while command line install grabs always general usage version of particular software.

So, it is up to you, what you’re going to use. I prefer command line (Gitosis) for — still — newest version and for much quicker access by typing than to clicking through many screens and pages in QNAP Control Panel.

Executing ipkg install gitosis command is only preliminary step.

At this stage, Gitosis installation isn’t complete and thus you don’t have to worry, that you’ll be serving something out or that you’ll put your QNAP into some kind of risk. So, using command line is an easy and convenient way of getting Git to your QNAP, even if you want to use Git only for updating local repositories and nothing more.

Getting your SSH keys

When browsing your QNAP thoroughly, you’ll find many places, where you have your key pairs. For example:

1. Installing Git using command line (above) will also generate you keys and put them into /opt/etc/openssh/ folder.
2. There are some keys stored in /etc/config/ssh/. I don’t know, where did they come from, but dates on my system suggest, that they were generated around initial installation of QNAP.
3. You can get some private RSA key (both above locations stored all keys in all formats) from QNAP’s control panel, by going to Control Panel > System Settings > Security > Certificate & Private Key and hitting Download Private Key button. I don’t know, where this key is stored and when it was generated. All I know, is that it is third one, because it content is different than content of private RSA kys in any of above locations.

Of course, you can use any private key in the context of this article, as long as it was generated on your QNAP and as long as authentication agent on your QNAP will provide it in response to public key request. And that’s the major problem.

If you’re using GitHub, you can execute ssh -T git@github.com from any folder in your QNAP, to verify, if it authenticates itself correctly, by providing valid private key in response to public key sent from GitHub. 99% chances that at this point the whole thing will fail.

You can execute the same command with -v switch (i.e. ssh -vT git@github.com) to run it in verbose mode. Look carefully for printed out results. You should notice line saying identity file /share/homes/admin/.ssh/. And here is our problem. Because, as you can see /share/homes/admin/.ssh/ location is not on our above list. This means, that your QNAP’s authentication agent is not using any of above mentioned keys. You can verify that, by executing:

cd /share/homes/admin/.ssh/
ls -ls

You should see an empty directory, with no actual SSH keys generated. So… we need to generate them.

Generate SSH keys

You can do this at any moment, by executing ssh-keygen -t rsa for any source or ssh-keygen -t rsa -b 4096 -C "your_email@example.com" specifically for GitHub. After generation process is over (10-30 seconds, according to your hardware) you have to tell ssh-keygen, where to put your keys.

Since it should already be /share/homes/admin/.ssh/ location, you only have to to hit Enter to confirm. Now, you should provide a passpharse or hit Enter twice to use keys without passphrases. Securing your keys with passphrase is the thing, that is always strongly suggested and that I never do! :>

If everything went, as supposed, you should have your private (id_rsa) and public (id_rsa.pub) keys in /share/homes/admin/.ssh/ folder.

Now, you must add your private key to your authentication agent. As GitHub manual suggests, you should start ssh-agent, by executing eval $(ssh-agent -s) (ssh-agent -s, if you’re using Git Bash) and then add your private key to it, by executing ssh-add ~/.ssh/id_rsa. This operation should be confirmed by Identity added: /root/.ssh/id_rsa message.

Upload SSH key to your remote

Once you have your key pair generated, you need to upload your public key to remote Git repositories server. I’ll use GitHub as an example.

Login to GitHub and jump to SSH Keys section, hit Add SSH Key, provide some distinct name and paste your public SSH key. Confirm by re-entering GitHub password.

Verify keys and conection

The fasted way to verify, if everything went fine, is to execute mentioned ssh -T git@github.com. If you see You've successfully authenticated, but GitHub does not provide shell access, then you’re done.

You can, of course, double-verify, that everything is OK, by going to any of your local repositories and executing git pull on them.

If see a message Error: Permission denied (publickey), you need to diagnose, what went wrong. This GitHub article could be a good starting point. Running text connection in verbose mode (i.e. ssh -vT git@github.com) can also be a source of inspiring ideas.

In fact, I have found and solved my problem, by carefully reading debug dumps of this command, before I actually got my hands on that GitHub article.