Linux 操作系统中的 /etc/shadow 文件有什么用途？另外，对于 SUSE 客户端来说也是一样吗？有一个影子缓存文件被维护，它有什么用途？
答案1
从一开始，Unix 和 Unix 风格的操作系统（包括 Linux）就一直将密码存储为加密哈希值 (1)。这些哈希值最初存储在 中/etc/passwd，但该文件需要是全球可读的，以便将信息用于其他目的 - 即使是简单的文件也ls -l需要读取/etc/passwd，以便将每个文件所有者的数字用户 ID 转换为其用户名以供显示。但是，将哈希密码放在全球可读的文件中，恶意用户可以轻松获取这些哈希值并尝试为其他用户的帐户生成可用的密码 (2)。
为了防止这种情况发生，散列密码最终被移至只有 root（有时是特权管理员组）可读的文件中。/etc/shadow这样可以隐藏系统的普通用户无法看到的散列，同时保持它们可用于用户身份验证目的。
笔记：
我知道这很迂腐，但存储的密码不是加密。它们使用加密安全的（至少在编写时）哈希算法进行哈希处理。这里的主要区别是哈希是固定长度的（加密文本的长度根据加密文本的长度而变化）和不可逆的（加密文本可以解密；哈希文本不能）。
由于哈希值的长度是固定的，因此有无数个输入可以匹配任何给定的哈希值表示。因此，攻击者可以找到一个有效的密码，该密码不一定与拥有该密码的用户的密码相同 - 尽管考虑到现代加密哈希值的大小，这种情况不太可能发生。
答案2
该/etc/shadow文件是出于安全原因而创建的，并保存了每个用户的加密密码。
最初，加密的密码存储在 中/etc/passwd， /etc/passwd必须是全世界可读的，以便系统可以将用户 ID 映射到用户名，并且用户可以找到彼此的信息，例如其他用户的主目录或他们的电话号码，这些信息传统上存储在“gecos”字段中并由“finger”实用程序显示。
但后来人们意识到这是一个安全问题。任何有足够时间的人都可以做所谓的蛮力攻击telnet，通过编程为每个可能的密码生成加密密码。如果攻击者这样做，而没有真正尝试通过或登录ssh，系统就无法知道它正在受到攻击。
因此加密的密码被移至新创建的文件中/etc/shadow，只有 root 可以读取。
它还包含/etc/passwd文件不支持的与用户帐户和密码相关的其他信息，例如密码上次更改的时间以及密码何时过期。
看man 5 shadow（网页版) 来了解文件格式的完整详情。
我不知道您使用的是哪个版本的 SUSE，因此无法确定 SUSE 是否也存在同样的问题。例如，您的 SUSE 系统可能使用 Blowfish 而不是 MD5。
您还暗示您将/etc/shadow文件与运行不同 Linux 发行版的系统混合在一起，但没有说明其他发行版是什么。
看将影子文件从 SuSE 9.3 迁移到 Ubuntu Server x86_64 时出现问题例如。
要弄清楚，请打开/etc/shadow并查看加密密码字段是否以$1$或开头$2$。如果它包含$1$，则它是 MD5，并且与大多数其他发行版兼容。如果它包含$2$，那么根据Debian 上的 Blowfish 影子文件。
如果你使用的是 Ubuntu，Ubuntu blowfish 的第一个 Google 搜索结果可能是一个很好的起点。
答案3
文件中列出了用户/etc/passwd。该文件包含系统使用的许多信息，不仅仅是为了允许用户登录。
每行对应一个用户条目，不同字段以冒号分隔。第一个字段是登录名，后面是相应的密码。
加密密码过去存储在此字段中。但是，该/etc/passwd文件必须可供系统上的每个人读取，因此加密无法防止暴力攻击，正如@Mikel 所说。解决方案是将这些加密密码移动到只有 root 可读的文件中：/etc/shadow。
因此，/etc/shadow包含系统用户的加密密码。当 中的密码字段/etc/passwd仅包含 x（表示“叉移至 /etc/shadow”）
答案4
让我们看看我是否能获得世界上所有的赞成票，因为我在 87 年编写了 Linux 影子密码套件；)
原始/etc/passwd文件包含经过修改的基于 DES 的明文密码哈希。在创建该函数时crypt()，人们认为（UNIX 操作系统的创建者也曾说过）针对密码哈希的攻击是不可行的，因为可能的密码数量以及使用 12 位（4,096 个可能值）“盐”。每个可能的明文密码都有 4,096 个可能的哈希值，加上 64 位哈希结果，总共可以得到 2^72 个可能的密码哈希。
正如另一位发帖者提到的，/etc/passwd各种实用程序也使用它来映射用户名和 UID 值（该/etc/group文件为组提供了类似的功能），并且要求它是全世界可读的。
在 1980 年代，很明显针对/etc/passwd文件中存储的密码哈希的字典攻击变得可行，并/etc/shadow在 System V 的早期版本中被引入到 AT&T UNIX。我记录了用于编写原始 Shadow 库的手册页，我已经忘记了，但它肯定是一个早期的 System V 版本，可能是 SVR3.2。
AT&T 所做的，以及我在 1987 年为 SCO Xenix（最初的 SCO Xenix，而不是后来邪恶的 SCO Xenix）实施的最终在 Linux 上投入使用的做法，只是将散列密码移动到/etc/shadow。这阻止了驱动攻击，即非特权用户获取 的副本/etc/passwd并对其进行攻击。如果您知道我最初编写 Shadow 的原因，那么我让用户/etc/passwd通过 UUCP 下载我的文件，当时我们仍然使用 UUCP 进行几乎所有事情。
当 Linux 诞生并得到广泛使用时，已经出现了大量用于攻击密码哈希的工具。高性能重新实现是crypt()其中一种途径，还有通过以下工具进行的基于字典的攻击：裂缝和破解还有其他人。初始移植由 Nate Holloway 和 Floria La Roche 完成（我把功劳给了他们，我不知道在他们之前是否有人做过这项工作）。
最终，即使在受保护的文件中，使用crypt()基于的哈希值也不再安全，并且对原始的MD5基于的哈希值进行了更改。MD5最终被认为太弱，并使用了较新的哈希值。
理论上，足够强的哈希值可以存储在 中/etc/passwd。较差的操作安全性意味着许多系统的/etc/shadow文件都可以通过各种攻击媒介获取——“我偷了备份文件”可能是最简单的。