首先，我知道，我应该使用SSH的密钥authentication。 没有必要解释我。
这里的问题是我有一大堆服务器，我需要一个脚本能够连接每个服务器。
我尽可能使用密钥身份validation，但是在每台服务器上都不可能（我没有控制权）。 所以SSHlogin，或有时telnet。
所以对于一些我只是将密码存储在一个数据库，我的脚本需要时采取。 问题是，这样做看起来并不安全。 有办法让它更安全吗？
像一些特定的存储方式？
如果您的脚本可以连接到这些服务器中的任何一个，那么任何有权访问该脚本的人（或脚本所运行的对该机器的特权访问）都可以连接到任何这些服务器。
如果脚本需要自主运行，则所有投注都将closures。 这里的答案是否定的，在这样的环境中存储密码并不是绝对安全的 。 没有绝对安全和实用的做法。
不要试图避免不可避免的，你应该把重点放在深度防御上 。
当然，当然，您应该充分保护密码 。 这通常意味着将它们保存在独立于脚本的文件中，并configuration限制性文件系统权限 。 从安全的angular度来看，这就是你可以在这方面做的所有事情。
其他措施肯定会使这一进程变得模糊不清 。 encryption密码将使攻击者需要search解密密钥。 使用某种操作系统受保护的存储通常可以防止其他用户访问您的密钥（所以它不会提供超过文件系统权限的优势，除了复杂的攻击和使用）。 这些措施会延缓攻击，但肯定不会阻止一个坚决的攻击者。
现在，让我们把密码公开一下。 你可以做什么来减轻损害？
一个久经考验的解决scheme是限制这些凭证可以做的事情。 在UNIX系统上，一个很好的方法是为脚本设置一个单独的用户，并限制该用户在访问和访问的服务器上的function。 您可以在SSH级别 ， shell级别 上限制用户function，也可以使用SELinux等强制访问控制机制 。
你也可能要考虑的是将脚本逻辑移入服务器 。 这样，你会得到一个更小的界面，更容易控制，特别是…
监视器 。 始终监视对服务器的访问。 优选地，日志authentication和命令执行为只追加日志 。 例如，不要忘记使用auditd监视脚本文件的更改。
当然，如果你不能控制服务器，许多这些机制是没有用的，正如你的问题似乎暗示的那样。 如果是这样的话，我build议你接触pipe理服务器的人 ，让他们知道你的脚本和潜在的安全隐患。
简短的回答是：没有。
漫长的回答是：不，没有完全安全的方法。 （这包括环境variables，服务器上的其他人可以访问这些variables。）最接近的就是将它们以某种encryption格式存储 – keepass，一个GPGencryption的文件，或者其他的东西。 但是在某些时候，您需要解密密码，以便您的脚本可以使用它，并且在那个时候您将会受到攻击。
换句话说，您需要在运行脚本的服务器，networking和目标服务器上深入了解安全性。
你可以使用第二个密码encryption你的数据库中的密码，并将这个密码存储在一个单独的（第三）机器上，并且有一个系统，需要密码的数据库的脚本首先连接第三台机器以获得解密密码，使用从第三台机器获得的密码解密数据库中的密码，然后工作。
当然这并没有增加任何额外的安全措施，具有足够特权的攻击者也可以从第三台机器请求密码。
但重要的是，第三方可以控制第三方机器，例如你的上司或安全官员，或第三方控制你不控制的服务器。
这样，你可以告诉他们，如果他们有任何问题，如果你辞掉了工作，他们不相信replace你的人，或者他们只是想让你的脚本停止访问他们的机器，他们可以在3日机器，你的脚本将不再有权访问密码。