如何安排一个带有密码的 ssh 密钥在 Windows 启动时加载并在 ssh-agent 中供其他进程使用?

如何安排一个带有密码的 ssh 密钥在 Windows 启动时加载并在 ssh-agent 中供其他进程使用?

我正在通过持续集成(TeamCity 构建代理)在 Windows 环境中设置应用程序的自动部署,并使用 cygwin + openssh 执行其中的远程执行部分 - 我基本上使用 ruby​​ 的 capistrano 和一堆自定义任务。

由于构建代理在盒子上作为 Windows 服务运行,因此它是无头的。盒子不与登录的用户一起运行,因此当(例如)钥匙串或选美比赛可能被加载时,用户没有机会输入密钥的密码。

所以目前,密码在部署脚本中是硬编码的 - 我的意思是,在一个地方,所以它不会分散在各处,但是,似乎必须有更安全的方法来做到这一点。

谁能告诉我这是什么?:-)

  • 我真的不想不是使用密码。
  • 我不希望每次重新启动构建代理时都手动登录到构建代理并执行某些步骤来为每个代理提供密码,以便可以加载密钥。

更新:

  • 我选择使用带密码的密钥,因为它似乎本质上更安全,直到后来我遇到了如何为无头流程解锁密钥的障碍。当时的想法是,只有拥有密钥密码的人才能部署。也许我想要一个(严格控制的)无密码密钥供 CI 构建代理使用,一个带密码的密钥供人类使用?

答案1

Windows 环境中的 SSH 是一种不常见的选择。大多数人会使用 WMI 来部署应用程序和管理远程系统。Jenkins-CI(以前称为 Hudson-CI)充分利用了 WMI 来实现此目的,因此请查看那里的示例。

但是,您使用的是 SSH,因此我建议您生成无需密码的 SSH 密钥。

与窃取或猜测常规密码相比,肩窥或猜测(未加密的) SSH 密钥更加困难。

将未加密的 SSH 与 IP 限制和日志监控相结合,这样如果有人窃取了密钥并尝试使用被盗密钥从另一台主机登录,您会立即知道。

如果您还没有:请考虑一种允许您的高价值主机连接到您的应用程序节点的设计,而不是相反。

如果您的(暴露的?)节点通过 SSH 连接到中央服务器以进行应用程序更新,请考虑使用 ForcedCommand 和 ChrootDirectory 来限制试图使用应用程序节点攻击您的黄金主机的攻击者可用的数据量。

相关内容