群辉Nas部署GitServer随笔

目的:在群晖上搭建一个 Git 服务器，用来管理代码版本，让团队协作更方便

以下内容为我自己研究的,仅供学习参考,生产环境慎用

一.环境搭建

|----------|----------------------------------------|
| 一台群晖 NAS | 已联网，能正常访问 DSM 桌面,同时安装了群辉自带的GitServer套件 |
| 群晖账号 | 管理员账号，用于后续操作 |
| 电脑 | Windows/Mac/Linux 均可，已安装 Git 客户端 |
| 局域网环境 | 电脑和 NAS 在同一网络下 |

我使用的是群辉自带的Git套件,当然你可以使用Docker部署其他Git服务

要注意的是:如果账号没法克隆仓库,可能是你这里忘记勾选了

管理员账号权限太大，用来日常 Git 操作不安全；Git 专用账号被 git-shell 锁在"笼子"里，只能执行 Git 命令，即使私钥泄露，破坏范围也仅限于仓库。

---

下面是群辉的文档,先查看一下

这里提到一个SSH,可能你不熟悉什么是SSH

SSH 是一种安全的远程操作协议，你可以把它理解成一条"加密的管道"------你在电脑上敲的命令，通过这条管道安全地传到群晖上执行，中间传输的内容都是加密的，不怕被偷听。

我们后面所有对群晖的远程操作（创建仓库、改权限等），都要通过 SSH 来完成。

我们需要在群辉桌面启动SSH功能

---

然后在个人电脑打开powershell

常见的三种登录,你能登录上即可

二.如何创建一对SSH 公钥私钥对

为什么需要这个？

SSH 免密登录的核心，就是把"密码"换成"钥匙"：

• 私钥 （id_rsa_synology）：放在你电脑上，绝不给任何人

• 公钥 （id_rsa_synology.pub）：放到群晖上，让服务器"记住"你

操作步骤

第 1 步：打开终端

Windows 用 PowerShell，Mac/Linux 用 Terminal。

第 2 步：执行生成命令

bash

ssh-keygen -t rsa -f ~/.ssh/id_rsa_synology -C "Synology"

参数说明：

参数	含义
-t rsa	指定使用 RSA 算法（最通用）
-f ~/.ssh/id_rsa_synology	指定生成的文件名（自己取，方便识别）
-C "Synology"	加个注释（方便以后辨认这把钥匙是干什么的）

第 3 步：一路回车

执行后会提示你输入密码（Passphrase）------直接按两次回车跳过，这样就是完全免密的。

第 4 步：确认生成成功

ls ~/.ssh/

你会看到两个新文件：

id_rsa_synology      ← 私钥（自己藏好）
id_rsa_synology.pub  ← 公钥（放到服务器上）

第 5 步：查看公钥内容

cat ~/.ssh/id_rsa_synology.pub

会输出类似这样的内容：

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDF... Synology

直接进去也能发现确实生成了, .pub是公钥放到你群辉的home/.ssh

复制整行，下一步要贴到群晖上去。公钥要放到你的home/.ssh目录下

公钥的名字必须是这个

私钥的文件名不重要！ 你取什么都行。id_rsa_synology 只是我们为了方便识别取的名字。关键是：

• ~/.ssh/config 里 IdentityFile 要指向正确的私钥文件

• 服务器上 authorized_keys 里要放对应的公钥内容

最后要注意的是,如果公钥不是账户拥有者自己创建的,而是别的账号直接复制进去的,那么文件所有权会导致你的公钥没法生效,将所有权改为自己

SSH Config 配置文件

这个文件是干什么的？

~/.ssh/config 是 SSH 客户端的配置文件，用来给常用的 SSH 连接设置"快捷方式"。

不用 config 时，每次都要输完整信息：

ssh -i ~/.ssh/id_rsa_synology 你的用户名@你的ip地址 -p 22

用了 config 后，只需要：

ssh nas

我的配置文件内容

Host nas
    HostName 你的ip地址
    User 你的用户名(管理员账号)
    Port 22
    IdentityFile ~/.ssh/id_rsa_synology

Host nas-git
    HostName 你的ip地址
    User 你的用户名(git账号)
    Port 22
    IdentityFile ~/.ssh/id_rsa_synology

各字段含义

字段	含义	我的值
Host	别名（快捷方式名）	nas / nas-git
HostName	服务器 IP 地址	地址
User	登录用户名	用户名
Port	SSH 端口	22（默认）
IdentityFile	指定用哪把私钥	~/.ssh/id_rsa_synology

用不同的 Host 区分不同用途

命令	实际连接	用途
ssh nas	管理员账号@IP地址:22	管理员登录，创建仓库、改权限
ssh nas-git	git专用账号@IP地址:22	Git 专用账号（但无法交互登录）
git clone ssh://nas-git/...	用 git专用账号 身份克隆	日常 Git 操作

存放位置

操作系统	路径
Windows	C:\Users\你的用户名\.ssh\config
Mac / Linux	~/.ssh/config

⚠️ 注意 ：文件名是 config，没有后缀名 （不是 config.txt）！

好处

1. 命令短 ：ssh nas 代替一长串参数

2. 统一管理：所有连接的账号、IP、私钥都集中在一个文件里

3. Git 也能用 ：git clone ssh://nas-git/... 会自动读取 config 里的配置

|---------------|----------------------------------------|
| SSH | 一种"安全的远程操作通道"，让你在电脑上能连接群晖nas工作 |
| 公钥 vs 私钥 | 私钥像你的"指纹"（绝不给别人），公钥像"指纹锁模板"（放到服务器上） |
| Git 裸仓库 | 没有"工作区"的仓库，只存版本历史，是远程协作的标准形态 |
| git-shell | 群晖把 Git 用户锁在一个"笼子"里，只能执行 Git 命令，防止乱搞系统 |

账号类型	角色	能做什么	不能做什么
Tom（管理员）	维护者	创建仓库、修改权限	（不建议日常 Git 操作）
Git_Tom（我的Git 工作账号）	Git 机器人	推送/拉取代码	SSH 登录终端
Jerry（普通账号）	开发者	推送/拉取代码	SSH 登录终端

三.创建Git仓库

我管理员只负责创建仓库,我们查看群辉的文档

很简单,前面你ssh处理好后登录后,按部就班即可

这里我创建了一个测试仓库

然后我需要转换所有权,把仓库给我的Git专用账号

sudo chown -R Git_Jerry:users .

|---------------|----------------------------------------------------------------------------------------------------------------------------------|
| sudo | 以管理员（root）身份运行。因为修改文件/文件夹的"拥有者"属于系统级操作，即便是管理员用户没权限，必须提权 |
| chown | Ch ange Owner（修改拥有者）的核心命令 |
| -R | R ecursive（递归）。意思是把 TestProject 文件夹本身 以及它里面所有的子文件和子文件夹 的所有权一起改掉。如果不加 -R，就只会改 TestProject 这个目录本身，里面的文件还是属于原来的用户 |
| Git_Jerry | 新的拥有者（Owner）。你要把文件夹交给谁？交给这个 Git 专用账号 |
| :users | 新的用户组 （Group）。冒号后面是用户组名，users 是群晖默认的普通用户组。意思是把文件夹的"组"也改成 users |
| TestProject | 要操作的目标文件夹名,因为我已经在该目录下,所以我要改成. |

以管理员身份，递归地将 TestProject 文件夹及其内部所有文件和子文件夹的拥有者改为 Git_Jerry，所属用户组改为 users。

成功使用我的git账号克隆了该仓库,也不用使用密码,因为我将公钥配置到~/ssh/authorized_keys

如果你使用小乌龟可能需要配置一下使用的ssh客户端,最好使用微软的ssh客户端,我测试git自带的ssh客户端有些不支持

四.文件夹权限处理

首先我们主要关注这三个组,users和admin两个组是群辉自带的,有一个规则就是所有账户默认都必须处于users组,这迫使我的管理员账号也处于这个组,导致我没法很好的把管理员和用户完全隔离开,所以我再创建一个basic组,将所有非管理员都放进去,而uses组不进行任何权限配置

这样在GitFile文件处我就可以细粒的控制权限,让我的Git账号有可读写权限,而其他普通用户则无法访问GitFile

如果你觉得权限管理没必要这么精细,那么可以直接

这样是省事,不需要给每个仓库分配权限,坏处是每个开发都可以看到所有的仓库,即使他没用参与某个项目,更进一步的是因为是可读写所以有删库的风险,尽量避免这种情况,这种方式过于粗放,而刚才的又有点过于细致,思路就是这么个思路,你可以自行调整