如其他答案中所述，您的凭据将在您的脚本可以访问的地方。

但我会把它们放在单独的配置文件中，你的脚本会读取它。

您将拥有以下优势：

• 您可以对多个系统使用相同的脚本（具有不同的配置文件）
• 您将能够与其他人共享脚本（或将其展示给某人而不会损害您的凭据）

您可以创建公钥/私钥对并加密密码。这应该会混淆临时路人的密码，因为他们只会知道他们知道的密钥的公共部分。

您还应该使用目录和文件权限来保护脚本。

此外，（取决于数据库）您应该能够为仅具有备份权限的数据库创建用户帐户。这将阻止某人创建表、转储表和替换内容。您可以将对该用户的访问限制为您希望备份运行的时间。

更新

Comodo 上的这篇文章实际上更好地解释了这些键。由于您担心有人可以访问代码中存在的原始密码，因此攻击者必须从触发脚本的用户那里监听私钥（这可能通过单独的 [virtual] 上的 cron 上的 SSH 发生机器）。显然，如果您将两个密钥都存储在同一个系统上，那将毫无意义，除非您存储的私钥当然具有比公钥更高的权限。

两个键一起 = 密码

关于权限，如果有人可以访问您的系统，并且非常担心以“可读格式”将密码存储在盒子上，这听起来像是盒子本身的权限配置存在更深层次的问题。此外，如果有人可以sudo击败您自己的特权（例如运行该框的主机），那么密钥散列实际上是防止管理员用户进入数据库的唯一选择。

此外，您需要禁用root数据库上的帐户，因为这将允许攻击者以任何方式读取数据库表。

考虑到脚本的自动化特性，我认为除了硬编码之外没有更好的方法来存储密码。

我的建议是使用适当的 unix 文件系统权限锁定脚本。制作脚本-rwx------并将所有者和组设置为适当的值将对保护密码大有帮助。

当然，有适当的日志记录措施来检测脚本是否已被破坏。如果有，请立即更改数据库服务器上的密码。

也许你问错了问题。虽然关注具有硬编码身份验证凭据的脚本是正确的，但真正的问题是如何管理自动化脚本使用的身份验证凭据，更重要的是，与系统相关的最高威胁或风险是什么。不同的系统有不同的风险。您需要了解与您的情况最相关的风险，以评估哪些行动最合适。一般来说

• 不要硬编码身份验证凭据。将它们放在单独的文件/位置，并让您的脚本使用这些信息。这样做的好处是可以更轻松地更改密码，因为您不需要编辑源代码，并且可以让多个脚本使用相同的源代码，从而允许您在一个地方更改密码。

• 了解权限、用途和组。使用可用的设施来限制访问。

• 使用操作系统的其他强化功能。例如，Linux 使用 SELinux 或 AppArmor（我认为 ubuntu 是基于 apparmor 的）。定义适当的策略以限制仅访问绝对必要的内容。

• 了解和使用可用的工具 - ssh、sudo、chroot 等。

了解和了解您的威胁所在将确定哪些技术和设施最适合，以及默认设施是否足够，或者您是否需要将事情提高一个档次并安装额外的预防措施。不要忽视审计和日志分析的重要性。保护到位是一回事。知道您的保护何时失败并且您已受到损害是另一回事。让您的系统受到损害可能很糟糕，但如果它被损害而不知道它，那就更糟糕了。