Jenkins中安全使用SSH的关键在于精细化管控凭证的类型、域、作用域及调用方式：优先选用SSH Username with private key类型，生成兼容PEM格式密钥；通过自定义Domain绑定主机名模式实现精准匹配；按最小权限原则设置Scope（避免滥用Global）；在Pipeline中严格使用withCredentials封装调用，确保密钥动态注入、自动清理、不泄露。
Jenkins 中安全使用 SSH 进行自动化操作，关键不在“能不能连上”，而在于“谁能在什么上下文里用哪个密钥、连哪台机器”。真正安全的实践，是把凭证的生命周期、可见范围和使用方式全部纳入设计——而不是等构建失败了再查私钥格式。
选对凭证类型：SSH 密钥优先，但要注意格式兼容性
避免使用用户名+密码类型进行 SSH 操作，它缺乏审计能力、易被暴力破解、且无法满足多数生产环境的合规要求。应统一采用 SSH Username with private key 类型。
但要注意：Jenkins（尤其搭配旧版插件时）对密钥格式敏感。OpenSSH 7.8+ 默认生成的 new-format 私钥（以 -----BEGIN OPENSSH PRIVATE KEY----- 开头）可能不被识别。
- 生成兼容性更强的密钥：用
ssh-keygen -t rsa -b 4096 -m PEM -f jenkins_id_rsa - 若已有新格式密钥，可转换：
ssh-keygen -p -m PEM -f id_rsa - 确保私钥内容完整粘贴（含首尾 BEGIN/END 行），无多余空格或换行截断
限定使用范围：用域（Domain）绑定主机，防误用
把所有 SSH 凭证扔进“全局”域，等于把所有房门钥匙串在一起挂墙上。正确做法是创建带规范的自定义域，让 Jenkins 自动过滤可用凭证。
- 例如：新建域
prod-servers，添加规范Hostname pattern: *.prod.example.com - 当在节点配置或流水线中填写
app01.prod.example.com时，仅该域下的凭证才会出现在下拉菜单 - 测试环境、预发环境、生产环境建议分设不同域，配合不同密钥对，实现物理隔离
控制访问权限：作用域（Scope）按需最小化
凭证的作用域决定谁能看到、谁有权调用。系统级任务（如 Agent 连接）才用 System；跨项目共享的只读凭据才用 Global；其余一律从 User 或 Folder 作用域起步。
- 部署脚本中调用的生产服务器密钥，不应设为 Global，而应放在对应项目文件夹的凭证域中
- 若使用 Folder 插件，可在文件夹层级创建凭证，只有该文件夹及其子任务能访问
- Jenkinsfile 中通过
withCredentials引用时，Jenkins 会自动校验作用域匹配性，不匹配则报错，这是第一道权限闸口
流水线中安全调用：避免硬编码，用 withCredentials 封装
明文写 ssh user@host 并附带密钥路径，是最大风险源。Jenkins 提供原生机制，在运行时注入凭证，并自动清理环境变量。
- Declarative Pipeline 示例：
stage('Deploy') {
steps {
withCredentials([sshUserPrivateKey(
credentialsId: 'prod-ssh-key',
keyFileVariable: 'IDENTITY_FILE'
)]) {
sh "scp -o StrictHostKeyChecking=no -i \$IDENTITY_FILE app.jar user@prod-server:/opt/app/"
sh "ssh -o StrictHostKeyChecking=no -i \$IDENTITY_FILE user@prod-server 'systemctl restart myapp'"
}
}
}
-
credentialsId必须与凭证实际 ID 一致（非描述名），可在凭证详情页 URL 中查看 - 密钥文件路径由 Jenkins 动态生成并注入，脚本无需关心存储位置，执行后自动销毁
- 整个块内环境变量（如
IDENTITY_FILE）对外不可见，防止日志泄露
