vmess-domain-rotator/git-push-authentication.md

Git Push 认证配置指南（无 Token 文件方案）

适用场景：每台服务器上都有完整项目；你会先手动 push 一次，并用 git config --global credential.helper store 保存凭据；之后 systemd 服务无交互自动 push runtime-state。

核心结论

可以，按你的逻辑完全可行：

1. 每台服务器手动配置 credential.helper store
2. 每台服务器手动 git push 一次（触发输入用户名/密码或 Token）
3. 后续服务定时任务可直接无交互 push

不需要 --git-http-token-file。

---

每台服务器的标准步骤

假设项目目录为 /home/aurora/vmess-domain-rotator，远端为 origin。

1) 先确认 remote 是 HTTPS

cd /home/aurora/vmess-domain-rotator
git remote get-url origin

必须是 https://...，例如：

https://git.example.com/aurora/vmess-domain-rotator.git

如果是 SSH 地址（git@...），就不是 credential store 这套流程。

2) 配置凭据持久化（服务用户）

git config --global credential.helper store

3) 手动 push 一次，触发保存凭据

你可以 push 任意分支（同一个 HTTPS 主机即可），例如：

git push origin main

首次会提示输入用户名与密码（或 Token），输入后会写入 ~/.git-credentials。

4) 安装 systemd 服务（不传 token 文件）

sudo bash scripts/install_debian.sh \
  --interval 1h \
  --git-push 1 \
  --git-use-credential-store 1

默认会使用当前 sudo 执行者作为服务用户（即 SUDO_USER）。

5) 验证服务是否能自动 push

sudo systemctl start vmess-domain-rotator.service
sudo journalctl -u vmess-domain-rotator.service -n 120 --no-pager

日志应看到：

• committed domain change on runtime-state ...
• pushed to origin/runtime-state

---

为什么这套流程可行

• run_update_and_commit.sh 在服务里是无交互执行（GIT_TERMINAL_PROMPT=0）。
• 但只要服务用户已在本机有可用凭据（credential.helper store + 曾成功 push），后续 push 不需要再交互。

---

换新服务器时怎么做

每台服务器都重复同样流程（凭据不会跨机器同步）：

1. git config --global credential.helper store
2. 手动 git push 一次保存凭据
3. 运行 install_debian.sh --git-push 1 --git-use-credential-store 1

即：一机一初始化。

---

常见坑

1. 服务用户不一致
   • 你是 aurora 手动保存的凭据，但服务跑在别的用户下，就读不到。
2. remote 不是 HTTPS
   • credential.helper store 对 SSH remote 不生效。
3. 凭据存储是明文
   • ~/.git-credentials 为明文，请确保服务器权限可控。