item 6（方案 A：GitHub Environment + 必须审批人 + SSH key 上强制
command=，通过 SSH 跑 deploy.sh）需要你在仓库里配置 SSH 私钥和主机 secrets
强制command=是什么？
文章目录
- SSH配置强制command=（Forced Command）介绍
- 具体含义
- 语法示例
- 在你的方案 A 中的作用
- ⚠️ 注意事项
SSH配置强制command=（Forced Command）介绍
在 SSH 配置中，强制command=（Forced Command）是一种安全机制，用于限制某个 SSH 密钥登录后只能执行特定的命令或脚本，而无论客户端请求执行什么命令。
具体含义
当你在服务器的~/.ssh/authorized_keys文件中为某个公钥添加command="..."选项时，SSH 服务端会忽略客户端传入的任何命令参数，转而强制执行你指定的那个命令。
语法示例
在部署服务器（如生产环境机器）的~/.ssh/authorized_keys文件中：
command="/opt/deploy/deploy.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3... deploy-key@github-actions在你的方案 A 中的作用
结合你提到的 “GitHub Environment + 必须审批人 + SSH key” 场景：
- 最小权限原则：即使 GitHub Actions 使用的这个 SSH 私钥泄露了，攻击者也无法通过该密钥登录服务器执行任意 shell 命令（如
rm -rf /、读取敏感文件等）。他们唯一能做的就是触发deploy.sh。 - 防止误操作：CI/CD 流水线中的脚本错误不会导致在服务器上意外执行危险命令，因为所有操作都被收敛到了
deploy.sh这一个入口点。 - 审计与合规：所有的部署行为都必须经过
deploy.sh，你可以在该脚本中统一记录日志、检查环境变量或验证部署令牌，确保只有合法的部署流程才能生效。
⚠️ 注意事项
- 安全性依赖脚本本身：如果
deploy.sh内部存在漏洞（例如直接将外部输入拼接到 shell 命令中），强制 command 的保护就会失效。务必确保deploy.sh是安全、幂等且不接收不可信输入的。 - 环境变量传递：强制 command 模式下，SSH 默认不传递客户端的环境变量。如果
deploy.sh需要参数，通常需要通过AcceptEnv配合或在脚本内从固定路径/Secrets 读取，而不是依赖 SSH 命令行参数。 - 配合其他限制：建议同时加上
no-pty,no-port-forwarding等选项，进一步收窄攻击面。
简而言之，强制command=就是把一把“万能钥匙”变成了一把“只能开特定门的专用钥匙”，是 CI/CD 场景中保护生产服务器 SSH 访问的最佳实践之一。
