使用SSH公钥的风险

是的，这是无密码SSH密钥的问题之一。 如果您在服务器A上存储了一个允许您连接到服务器B的私钥，那么获得对服务器A的访问将有效地获得对服务器B的访问权限。（反过来不是这样，获得对服务器B的访问不会导致立即妥协的服务器A，假设你没有设置SSH密钥，允许在这个方向无密码login。

有几件事你可以做，以缓解这一点：

• 如果进程不需要完全自动化，请在SSH密钥中添加一个密码。 （这可能不适合你，因为你注意到这是备份）
• 对于在您自己的帐户下无密码login到多台计算机，我build议为您物理键入的每台计算机创build一个密码密钥，并在使用时使用SSH代理将密钥存储在内存中。 代理转发应允许您从主机“跳”到主机，而无需在每个远程主机上创build密钥。
• 对于自动化，无密码的SSH密钥，我build议限制密钥可以运行的命令。 在您的authorized_keys文件中，为每个键添加前缀：
  command=" <allowed command line here> ",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8 – 9年前，我在一个拥有数百名本地用户的共享用户环境中工作，基于SSH密钥的login被禁用，因为没有办法对密钥实施密码策略。 只要你完全控制这个场景，现在的SSH密钥肯定比使用密码更好。

是的，互联网上的大多数指南停止获得无密码的SSH工作，而不是让它安全地工作。 本指南很好地展示了如何降低风险。 基本上（引用文章）：

• 为该作业创build一个单一用途的angular色帐户：即每台机器上的用户dnssync
• 如果可行的话，使该文件可由该用户写入，而不是依赖于根
• 对于真正需要特权访问的那些位，创build一个脚本来执行它，并使用sudo
• 使用authorized_keys文件中的command=和from=选项来限制密码短语密钥
• 为了进行文件传输，在接收机上使用rsync编写脚本来完成，以便远程访问可以是只读的
• 如果这意味着需要从远程机器访问返回到启动机器，则使用ssh-agent而不是创build第二个无密码短语密钥

ssh密钥有几个问题：

没有集中的方式来撤销密钥。

没有办法强制密码政策的关键（是你的私人密钥encryption，如果是的话，它是用一个好的密码encryption？）。

这些是Kerberos解决的问题。 然而，它引入了其他的，即实现起来更复杂，需要一个真正的用户pipe理基础设施来部署和pipe理。

在任何情况下，虽然ssh authorized_keys允许morris-wormtypes的攻击，但它仍然比.r服务和telnet更好（以英里（光年）

在任何我能控制的环境中，我一直是一个真正的坚持者，为服务账户尽可能less的权限。

在这种情况下，我build议确保远程服务器上的用户帐户只允许运行一小组，严格定义的可执行文件。 您可以使用远程端的多个帐户和sudo来完成此操作。

即使在这种情况下，您仍然受到本地特权升级错误的影响，所以要一丝不苟，严密追踪安全漏洞。