我之前也碰到过类似的场景，核心就是要把VMA上的RepoA访问权限和RepoB完全隔离开，不让协作者有可乘之机。不用新建用户的话，GitLab的部署密钥+SSH配置是最靠谱的方案，具体步骤如下：

• 第一步：为RepoA生成专属的部署密钥
  在VMA上生成一对只用于RepoA的SSH密钥，避免和你个人的全局密钥混用：

  ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_repoa -C "vma-repoa-deploy-key"
  

  生成过程中直接按回车跳过密码设置（或者设置密码后告知协作者，按需选择），最终会得到id_rsa_repoa（私钥）和id_rsa_repoa.pub（公钥）两个文件。

• 第二步：把公钥添加到RepoA的部署密钥中
  登录GitLab进入RepoA的设置页面，找到「部署密钥」选项，点击「添加密钥」：

  • 粘贴id_rsa_repoa.pub里的内容到密钥输入框
  • 给密钥起个好记的名字（比如VMA-RepoA-Deploy）
  • 根据需求勾选「允许写入」（如果协作者需要推送代码），仅需拉取则无需勾选
  • 保存后，这个密钥就只会拥有RepoA的访问权限，完全无法访问RepoB

• 第三步：配置VMA的SSH规则，强制访问RepoA时用专属密钥
  编辑VMA上的~/.ssh/config文件（没有的话直接新建），添加以下配置：

  Host gitlab-repoa
    HostName <你的GitLab域名>  # 比如gitlab.com或者你的私有GitLab地址
    User git
    IdentityFile ~/.ssh/id_rsa_repoa
    IdentitiesOnly yes  # 强制使用指定密钥，避免 fallback 到其他密钥
  

  然后把VMA上RepoA的远程仓库地址修改为这个自定义Host：

  git remote set-url origin gitlab-repoa:<你的用户名>/RepoA.git
  

  这样不管是拉取还是推送RepoA，都会自动用专属的部署密钥，不会用到你个人的全局密钥。

• 第四步：确保VMA上的个人密钥安全隔离
  如果你自己需要在VMA上访问RepoB，建议：

  1. 给RepoB也生成一个单独的部署密钥，同样配置SSH config（比如Host gitlab-repob，对应RepoB的密钥）
  2. 把你个人的全局SSH密钥从VMA上移除，避免协作者接触到
  3. 若必须保留个人密钥，一定要设置严格的文件权限：

     chmod 600 ~/.ssh/id_rsa
     chmod 700 ~/.ssh
     

     确保协作者的用户账号没有权限读取你的个人密钥文件。

这样设置后，协作者在VMA上只能通过专属部署密钥访问RepoA，哪怕他猜到RepoB的地址，用这个密钥尝试访问也会被GitLab拒绝——因为部署密钥是项目级的，只绑定RepoA，完全没有RepoB的权限。

内容的提问来源于stack exchange，提问作者Simion Bogdan