![通过 ssh 运行的自动运行 cron 作业的密钥是否应该没有密码?](https://linux22.com/image/68406/%E9%80%9A%E8%BF%87%20ssh%20%E8%BF%90%E8%A1%8C%E7%9A%84%E8%87%AA%E5%8A%A8%E8%BF%90%E8%A1%8C%20cron%20%E4%BD%9C%E4%B8%9A%E7%9A%84%E5%AF%86%E9%92%A5%E6%98%AF%E5%90%A6%E5%BA%94%E8%AF%A5%E6%B2%A1%E6%9C%89%E5%AF%86%E7%A0%81%EF%BC%9F.png)
我正在阅读Master Linux Now 2013
名为的一篇文章OpenSSH: Easy Logins
,它ssh-agent
允许您输入一次密钥密码,然后您就可以自由连接到远程计算机,而无需在 ssh-agent 运行时再次输入密码。
我最初被这篇文章吸引的原因除了不必重新输入密码一百万次之外;这样我就可以通过 ssh 从远程到服务器的计算机上的 cron 调用 rsync,从 / 到远程计算机进行无人值守的备份;
我看到另一篇文章,有人只是跳过了密码短语,以便 cron 可以轻松地使用密钥登录,感觉不太对,但是在实践中这样做可以吗?我的意思是,如果有人掌握了该密钥文件,他们就能够对正在备份的机器造成严重破坏。
在我看来,确保用户在重新启动时登录并让他们在登录以运行代理时输入密码一次,然后等待 cron 作业在屏幕锁定的情况下运行会更安全;但我可能在这里遗漏了一些东西,比如关于 cron 作业运行的用户或用户类型。
答案1
限制按键可以调用的命令
如果 SSH 密钥将用于任何类型的自动化或无人值守任务,您应该限制它能够在远程计算机上执行的命令,无论您对如何以及在何处存储密钥做出什么决定。
在中使用类似的东西~/.ssh/authorized_keys
:
command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....
这样,至少钥匙不应该像你所说的那样造成严重破坏。它只能访问它应该访问的内容,等等...它很可能仍然会造成损害,但它对远程系统的访问权限应该低于完全访问权限。
您还可以限制允许使用该密钥进行连接的 IP 地址,并禁用许多其他 SSH 功能,例如使用该密钥的连接的端口转发:
from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....
所有这些都必须在~/.ssh/authorized_keys
.
保护密钥
这取决于您的威胁模型是什么。
如果您担心密钥在“冷”时被盗,例如,保存密钥的计算机被物理窃取,那么您不会希望在该位置没有密码短语的情况下保存它。
你可以在服务器启动后手动启动一种后台 SSH 代理,将密钥添加到该代理,并记录该代理的密钥$SSH_AUTH_SOCK
以供 cron 作业将来使用,但老实说,这听起来比它的价值更麻烦。您也可以将未加密的密钥存储在tmpfs
文件系统中,并让 cron 作业从那里访问它。无论哪种方式,密钥仅存在于内存中(如果您没有交换或加密交换)。当然,您应该chown
使用chmod
该文件,以便只有目标用户才能访问它。
话又说回来,如果您担心这一点,您可能已经使用加密的根文件系统和交换(例如 luks)设置了这台计算机,因此您可能不需要担心它。
如果您担心密钥在“热”(加载到内存中)时被盗,那么您对此无能为力。如果 cron 作业可以访问它,那么其他已成功获得相同访问权限的东西也可以。就是这样,或者放弃无人值守作业执行的便利。
总之,您应该将备份服务器视为一个非常特权的系统,因为它必然会被授予对其备份的所有计算机的完整文件系统的只读访问权限。例如,您的备份服务器不应通过 Internet 访问。