使用 ssh 公钥的风险

使用 ssh 公钥的风险

我有服务器A服务器B(备份),我想知道,如果有人闯入服务器 A,如果我已经使用 ssh 公钥配置了无密码登录,闯入服务器 B 是否会有潜在危险?

我正在尝试设置 rsnapshot。

谢谢

答案1

是的,这是无密码 SSH 密钥的问题之一。如果您在服务器 A 上存储了允许您连接到服务器 B 的私钥,则访问服务器 A 实际上就是访问服务器 B。(反之则不然 - 访问服务器 B 不会导致服务器 A 立即被攻陷,前提是您没有设置 SSH 密钥以允许无密码登录。)

您可以采取一些措施来缓解这种情况:

  • 如果该过程不需要完全自动化,请为您的 SSH 密钥添加密码。(这可能不适合您,因为您注意到它是为了备份)
  • 对于使用您自己的帐户无密码登录多台机器,我建议为您实际输入的每台机器创建一个密码密钥,并在使用时使用 SSH 代理将密钥存储在内存中。代理转发应该允许您在主机之间“跳跃”,而无需在每个远程主机上创建密钥。
  • 对于自动化、无密码的 SSH 密钥,我建议限制密钥可以运行的命令。在您的authorized_keys文件中,为每个密钥添加前缀:
    command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 年前,我在一个有数百名本地用户的共享用户环境中工作,由于无法对密钥强制执行密码策略,因此基于 SSH 密钥的登录被禁用。只要您完全控制场景,如今 SSH 密钥绝对比仅使用密码要好。

答案2

是的,互联网上的大多数指南都止步于让无密码 ssh 工作,而不是让它安全地工作。本指南很好地展示了可以采取哪些措施来降低风险。基本上(引用文章):

  • dnssync为该作业创建一个单一用途的角色帐户:即每台机器上的用户
  • 如果可行,请让该用户可写入文件,而不是依赖于 root
  • 对于真正需要特权访问的部分,请创建一个脚本来执行此操作,并使用 sudo
  • 使用command=和文件from=中的选项authorized_keys来限制无密码密钥
  • 为了进行文件传输,编写一个脚本来使用 rsync 进行传输,接收机器,以便可以进行远程访问只读
  • 如果这意味着需要从远程计算机访问启动计算机,则使用ssh-agent而不是创建第二个无密码密钥

答案3

ssh 密钥存在一些问题:

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

无法对密钥强制执行密码策略(您的私钥是否加密?如果是,是否使用好的密码加密?)。

这些就是 Kerberos 所解决的问题。但它也带来了其他问题,即它的实现更加复杂,并且需要部署和管理真正的用户管理基础设施。

无论如何,尽管 ssh authorized_keys 允许莫里斯蠕虫类型攻击,它仍然比.r 服务和 telnet 好几英里(光年)

答案4

在我控制的任何环境中,我始终坚持为服务帐户提供尽可能少的权限。

在这种情况下,我建议确保远程服务器上的用户帐户仅被允许运行一小部分严格定义的可执行文件。您可以在远程端使用多个帐户并使用 sudo 来实现这一点。

即使在这种情况下,您仍然会受到本地权限提升漏洞的影响,因此要细心并密切跟踪安全漏洞。

相关内容