Instructions for setting up a git server on a Synology NAS with Diskstation. Specifically, I am using a DS414 with DSM 5.0.
- Create user
gituser
via Diskstation interface (with File Station and WebDAV privilages) - Add new shared folder called
git
(located at/volume1/git
) with read/write access forgituser
andadmin
. This folder will hold all the repos. - Install Git Server package via Diskstation
- Open Git Server and allow
gituser
permissions - Enable SSH access on Diskstation (Control Panel > Terminal & SNMP > Enable SSH Service)
- create
~/.ssh
folder for gituser on server
ssh [email protected]
mkdir /volume1/homes/gituser/.ssh
- copy public rsa key from local computer to gituser account on server
scp ~/.ssh/id_rsa.pub [email protected]:/volume1/homes/gituser/.ssh
- connect via SSH as
root
and renameid_rsa.pub
toauthorized_keys
on NAS (or append if already exists,cat id_rsa.pub >> authorized_keys
)
ssh [email protected]
mv /volume1/homes/gituser/.ssh/id_rsa.pub /volume1/homes/gituser/.ssh/authorized_keys
- change permissions while logged in as root
cd /volume1/homes/gituser/
chown -R gituser:users .ssh
chmod 700 .ssh
chmod 644 .ssh/authorized_keys
- create bare repo as root
ssh [email protected]
cd /volume1/git/
git --bare init <repo-name>.git
chown -R gituser:users <repo-name>.git
cd <repo-name>.git
git update-server-info
NOTE: I'm not entirely sure if git update-server-info
must be run for each repo or just initially. It seems to work without running this command, but I'm suspcicious that it might cause problems later.
- Clone repo from NAS
git clone ssh://[email protected]/volume1/git/<repo-name>.git
http://blog.osdev.org/git/2014/02/13/using-git-on-a-synology-nas.html http://stackoverflow.com/questions/20074692/set-up-git-on-a-nas-with-synologys-official-package http://www.heidilux.com/2014/02/setup-git-server-synology-nas/
Six years on and this still seems the best documentation available for this process - thank you. Unfortunately I did not find it until near the end of the process.
In my case I was using DSM 7.1.? and then then found I could manually upgrade to 7.2.1.
Each version upgrade seems to tie the system down even tighter in terms of "security", but the measures taken seem to me somewhat arbitrary. There are at least three layers of actively blocking me trying to get a login shell for the git user (just so I can get things set up).
Here are some other observations people might find useful
Openssh requirements for public key use.
From the manual for opensshd, on Linux systems it requires only that group and other permissions are set to be not writable. Whether you apply mode 0600, 700, 711 or 755 should not make any difference. As mentioned, this requirement applies to:
What I don't know the answer to is how much DSM's default to inherited ACL permissions breaks this.
The presence of a "+" in the permission list of
ls -l
indicates ACLs are in operation and the unix-mode flags are fabrications. In some cases, different users will see different flags shown for the same directory.Using
chmod
on a file or directory will disable the ACLs and assign the unix-mode values you have specified, but if your home directory is not set suitably then you may think it is safe, but to root it reports as world- or group-writable.In the end, I used the undocumented
synoacltool
to remove inheritance and delete write-access to 'admin'. So, the lesson is, if you see a "+" on the permission flags withls
then apply a chmod, even if the values already look ok.Did Synology modify opensshd to take ACLs into account? I doubt it.
sftp chroot
Another thing that threw me for a bit was that ssh in a default config will log you in with access to the full file system. However,
sftp
andscp
do something like a chroot and they only expose shared folders you have permission to access.So, what looks like /volume1/gitfiles/ when you log in, becomes /gitfiles under sftp and scp. And the default starting folder with scp is not your home dir - I've not found a way that does not need a full path specified.