通过脚本以安全的方式生成 SSH 密钥对

发布于 2024-11-04 05:32:54 字数 227 浏览 4 评论 0原文

我需要生成一个 SSH 密钥对,稍后我将在程序中使用它,因此需要它们作为字符串。不幸的是,ssh-keygen 实用程序不支持将密钥写入 STDOUT 或类似内容。

因此,“下一个最好的事情”是让 ssh-keygen 将其输出写入临时文件,然后我可以将其读回到程序中。然而,这会带来系统上其他人读取私钥文件的风险(该脚本将由 Web 应用程序运行)。

如何以安全的方式生成密钥对?

I need to generate an SSH key pair that I'll be working with later in the program, and therefore need them as strings. Unfortunately, the ssh-keygen utility doesn't support writing the keys to STDOUT or something the like.

So, the "next best thing" would be to have ssh-keygen write its output to temporary files, which I can then read back into the program. This however poses the risk of somebody else on the system reading the private keyfile (the script will be run by a web app).

How can I generate a key pair in a way that is secure?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

雨巷深深 2024-11-11 05:32:54

没有完全安全的方法来生成用于分发的私钥;最安全的方法是让每个客户端生成其密钥对并仅传输公钥。

但是,如果您处于这种情况根本行不通,并且您致力于集中生成密钥对,那么您确实有一些选择。

有硬件安全模块 (HSM) 可以为您执行此操作。如果你能负担得起,这是最好的选择。

如果失败:

  1. 确保您的网络应用程序或密钥生成器包装器在其自己的用户下运行(在本答案的其余部分中,我将称该用户为“kguser”)。
  2. 创建一个由 kguser 拥有的不可通过 Web 访问的目录,权限为 0700(使用 chmod 设置)
  3. 确保您的密钥生成器包装器设置为“umask 0177”;这应该确保它创建的任何文件都是 0600 (只有 kguser 能够读写)
  4. 生成指定难以猜测(例如随机 UUID)文件名的密钥
  5. 生成密钥文件后立即 chmod 0600 密钥文件,只需如果您的 umask 设置不保留或被更改
  6. 通过 SSL/TLS 连接传输私钥
  7. 安全地删除私钥文件(例如 Linux 上的“粉碎”)
  8. 使用 cron 作业定期查找并安全地删除任何私钥文件超过几分钟(以清理由于应用程序错误、崩溃等而留下的任何文件)。

如果您真的很偏执,您还可以通过让您的 Web 应用程序使用密钥来确保密钥在磁盘上进行加密它自己的对称密钥在写入时加密并在发送给用户时解密。然而,这会导致更多的密钥管理失败,所以我不推荐它。

如果您从不将该密码存储到磁盘,则在密钥上设置密码也会有很大帮助。如果有人确实设法恢复受密码保护的密钥,他们仍然必须猜测密码才能使密钥有用。然而,这也意味着您的用户在使用密钥时必须提供密码——这可能可接受也可能不可接受。

There is no perfectly secure way to generate private keys for distribution; the most secure way is to have each client generate its keypairs and only transmit the public key.

However, if you're in a situation where that simply won't work, and you're committed to generating keypairs centrally, you do have a few options.

There are Hardware Security Modules (HSMs) that do this for you. If you can afford it, this is the best way to go.

Failing that:

  1. Ensure your web-app or the key-generator wrapper runs under its own user (I'll call this user 'kguser' for the rest of this answer).
  2. Make a non-web-accessible directory owned by kguser, with permissions 0700 (set with chmod)
  3. Make sure your key-generator wrapper sets 'umask 0177'; that should ensure that any files it creates are 0600 (only kguser will be able to read and write)
  4. generate your keys specifying hard-to-guess (e.g. Random UUID) file names
  5. chmod 0600 the key files as soon as you generate them, just in case your umask setting doesn't hold or gets changed
  6. transmit the private key via an SSL/TLS connection
  7. securely erase the private key file (e.g. 'shred' on Linux)
  8. use a cron job to regularly find and securely erase any private key files older than a few minutes (to clean up any files that are left due to an application error, crash, etc.)

If you're really paranoid, you can also ensure that the keys are encrypted while on disk by having your web application use its own symmetric key to encrypt on writing and decrypt when sending to the user. However, that opens up more key-management to screw up, so I don't recommend it.

Setting a passphrase on the key will help a lot as well, if you never store that passphrase to disk. If someone does manage to recover a passphrase-protected key, they still have to guess the passphrase for the key to be useful. However, this also means your users will have to provide a passphrase when they use the key -- this may or may not be acceptable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文