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.
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:
- Installing Git using command line (above) will also generate you keys and put them into
- 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.
- 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 Keyand hitting
Download Private Keybutton. 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 email@example.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 firstname.lastname@example.org) 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 "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
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 firstname.lastname@example.org. 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 email@example.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.