介绍(服务器~/.ssh/authorized_keys)限定命令范围)
item 6方案 AGitHub Environment 必须审批人 SSH key 上强制command通过 SSH 跑 deploy.sh需要你在仓库里配置 SSH 私钥和主机 secrets强制command是什么文章目录SSH配置强制commandForced Command介绍具体含义语法示例在你的方案 A 中的作用⚠️ 注意事项SSH配置强制commandForced Command介绍在 SSH 配置中强制commandForced 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-keygithub-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 访问的最佳实践之一。