ssh密钥是ci稳定运行的关键基础设施，用于自动、安全、免交互地访问代码仓库或部署目标；它避免http/https的rpc错误，解决凭据硬编码、泄露及token过期等问题，支持git拉取与远程部署两大场景，并需遵循最小权限、密钥隔离、ed25519算法、严格权限与定期轮换等安全实践。
SSH 密钥在持续集成（CI）中主要解决的是「自动、安全、免交互地访问代码仓库或部署目标」的问题。它不是可选项，而是稳定运行 CI 流水线的关键基础设施。
为什么 CI 必须用 SSH 密钥？
HTTP/HTTPS 协议拉取代码时容易触发 RPC 错误（比如 error: RPC failed; curl 56），尤其在大仓库、弱网络或 CI 节点资源受限时。SSH 协议基于 TCP 长连接，传输更鲁棒；更重要的是——它不依赖密码，避免了凭据硬编码、环境变量泄露、Token 过期等运维痛点。
典型使用方式：两种主流场景
1. 从 Git 仓库拉取源码
CI 工具（如 Jenkins、GitLab CI、GitHub Actions 自托管 runner）需要克隆代码。此时需在构建节点上配置 SSH 私钥，并把对应公钥添加到仓库的「Deploy Keys」或「SSH Keys」设置中：
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
- 推荐为 CI 单独生成密钥（如
ssh-keygen -t ed25519 -f ~/.ssh/ci_deploy_key -C "ci@project"），避免复用个人密钥 - 公钥添加到 GitHub/GitLab 的项目级 Deploy Keys（只读）或账户级 SSH Keys（读写），按最小权限原则选择
- Jenkins 等平台支持「Credentials Binding」插件，可安全注入私钥到构建环境，无需明文写入脚本
2. 向远程服务器部署产物
构建完成后，常需通过 scp 或 rsync 推送二进制包、或用 ssh 执行部署命令：
- 私钥应预置在 CI 构建节点（如 Jenkins agent）的
~/.ssh/下，并确保权限为600 - 目标服务器的
~/.ssh/authorized_keys中需有该私钥对应的公钥，且服务端sshd_config开启PubkeyAuthentication yes - 建议配合
~/.ssh/config定义 Host 别名和 IdentityFile，让部署脚本简洁可靠
安全与实践要点
CI 环境下的密钥管理容错率极低，以下细节直接影响安全性与可用性：
- 绝不将私钥明文写入 CI 脚本或版本库；使用平台内置凭证管理（如 Jenkins Credentials、GitLab CI Variables 加密字段）
- 密钥建议用
ed25519算法（OpenSSH ≥6.5 支持），比 RSA 更快更小更安全；若需兼容旧系统，选rsa -b 4096 - 为 CI 密钥设置 passphrase 并配合
ssh-agent解锁（如ssh-add -D && ssh-add ~/.ssh/ci_deploy_key），但需注意 CI 环境是否支持交互式输入——通常改用无密码密钥 + 严格文件权限替代 - 定期轮换 CI 密钥（如每季度），并及时从所有仓库和服务器移除旧公钥
多环境/多仓库怎么管？
一个 CI 流水线可能涉及多个 Git 仓库（主仓、依赖子模块、私有包仓）或多个部署目标（测试服、预发服、生产服）。这时不能只靠一套密钥：
- 为不同用途生成独立密钥对，命名清晰（如
gitlab-ci-deploy、prod-server-key） - 用
~/.ssh/config做路由映射，例如：Host gitlab.com<br> HostName gitlab.com<br> User git<br> IdentityFile ~/.ssh/gitlab_ci_key
- 在 CI 脚本中通过
git clone git@gitlab.com:group/repo.git自动命中对应密钥，无需额外参数
