我正在阅读一篇Master Linux Now 2013名为的文章，OpenSSH: Easy Logins它ssh-agent允许您为您的密钥输入一次密码，然后您就可以自由地连接到远程机器，而无需在 ssh-agent 运行时再次输入。
我被这篇文章吸引的最初原因，除了不必重新输入一百万次密码之外；以便我可以通过 ssh 从远程机器上的 cron 调用 rsync 从/到远程机器进行无人值守备份；
我看到另一篇文章，有人只是跳过了密码，以便 cron 可以轻松地使用密钥登录，感觉不对，但在实践中这样做可以吗？我的意思是，如果有人掌握了该密钥文件，他们将能够对正在备份的机器造成严重破坏。
在我看来，确保用户在重新启动时登录并让他们输入一次密码会更安全，当他们登录以使代理运行时，然后等待 cron 作业在屏幕锁定的情况下运行；但我可能在这里遗漏了一些东西，比如用户或用户类型的 cron 作业运行。
如果 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 访问。