首先，我知道我应该使用 SSH 进行密钥认证。无需向我解释。
这里的问题是我有一大堆服务器，我需要一个脚本能够连接这些服务器。
我尽可能使用密钥身份验证，但并非每台服务器都可使用（我无法控制这一点）。因此请使用 SSH 登录，有时也使用 telnet。
因此，对于某些用户，我只是将密码存储在数据库中，然后我的脚本在需要时获取密码。问题是，这样做看起来不太安全。有没有办法让它更安全一点？
比如某种特定的存储方式？
答案1
如果您的脚本可以连接到任何这些服务器，那么任何有权访问该脚本（或有权访问运行该脚本的机器）的人都可以连接到任何这些服务器。
如果脚本需要自主运行，一切都无法预料。答案是不，在这样的环境中没有绝对安全的方法来存储密码. 没有绝对安全和做任何事情的实用方法。
你不应该试图避免不可避免的事情，而应该专注于纵深防御。
首先，当然，你应该充分保护密码.这通常意味着将它们保存在与脚本分开的文件中，并配置限制性的文件系统权限。从安全角度来看，这就是您在这方面能做的一切。
其他措施肯定可以增加朦胧到该过程。加密密码将使攻击者需要搜索解密密钥。使用某种操作系统保护的存储通常可以防止其他用户访问您的密钥（因此它与文件系统权限相比没有任何优势，除了攻击和使用起来很复杂）。这些措施将延迟攻击，但肯定无法阻止针对坚决攻击者的攻击。
现在，让我们将密码视为公开片刻。你能做些什么来减轻损害？
一个经过测试的老办法是限制这些凭据可以执行的操作。在 UNIX 系统上，一个好办法是为你的脚本设置一个单独的用户并限制该用户的功能，无论是在访问服务器还是被访问服务器上。您可以限制用户能力在 SSH 级别，在外壳级别或者可能使用强制访问控制机制，如 SELinux。
你可能还想考虑的是将脚本逻辑移至服务器。这样，您将获得一个更小、更易于控制的界面，尤其是……
监视器始终监控对服务器的访问。最好将身份验证和执行的命令记录到仅附加日志auditd。例如，不要忘记使用 来监视脚本文件的变化。
当然，如果你无法控制服务器，那么这些机制中的许多都是无用的，正如你的问题所暗示的那样。如果是这样的话，我建议你与管理服务器的人员取得联系并让他们了解您的脚本和潜在的安全隐患。
答案2
最简洁的答案是不。
长话短说：没有，没有完全安全的方法。（这包括环境变量，服务器上的其他人可以访问它们。）最接近的方法就是将它们存储在某种加密格式中 - keepass、GPG 加密文件或其他类似的格式。但有时您需要解密密码，以便您的脚本可以使用它，这时您将容易受到攻击。
换句话说，您需要认真考虑深度安全性，包括运行脚本的服务器、网络和目标服务器。
答案3
您可以使用第二个密码加密数据库中的密码，并将该密码存储在单独的（第三台）机器上，并建立一个系统，其中需要从数据库中获取密码的脚本首先连接第三台机器以获取解密密码，使用从第三台机器获得的密码解密数据库中的密码并完成其工作。
当然，这实际上并没有增加任何额外的安全性，具有足够权限的攻击者也可以从第三台机器请求密码。
但关键是第三方可以控制第三方机器，例如你的老板或安全官员，或者控制你无法控制的服务器的第三方。
这样，您就可以告诉他们，如果他们遇到问题，如果您辞职并且他们不信任替代您的人，或者他们只是想让您的脚本停止访问他们的机器，他们可以拔掉第三台机器的插头，您的脚本将不再有权访问密码。