Linux 集中登录选 LDAP、SSH CA 还是 Ansible

集中管理 Linux 登录时，实际需要的是什么

大多数希望集中管理 Linux 登录的管理员只需要一件事：添加用户时只添加一次，删除用户时只删除一次，并让所有服务器保持一致。目录服务可以实现这一点。但对于由六台 VPS 实例组成的服务器集群，目录服务也是最脆弱的实现方式，因为目录服务一旦无法访问，所有机器可能会同时拒绝登录。

有三种方式可以实现“修改一次，所有主机都遵循”。可以运行 OpenLDAP 或 FreeIPA 等目录服务，并在每台主机上使用 SSSD（系统安全服务守护进程）。也可以从自己的证书颁发机构（CA）签发短期 SSH 证书。还可以通过配置管理系统写入用户账户和 authorized_keys 文件。本文将从吊销速度、服务中断期间的行为、sudo 策略、审计记录和部署成本等方面评估这三种方式，然后根据服务器集群规模给出建议，而不是指定唯一的最佳方案。

安装 OpenLDAP 前，先验证前提

LDAP（轻量级目录访问协议）集中管理身份信息：用户名、数字用户 ID、组成员关系，通常还包括密码。这就是它的功能。它不会分发 SSH 公钥，不会决定谁可以运行 sudo，也不会记录谁从哪里登录。每项功能都需要在其上单独配置。团队安装 OpenLDAP 时，往往期待得到完整的访问控制系统，最终却要维护一个包含架构、访问控制语法和复制拓扑的数据库。

因此，在选择方案前，先写明实际需求。通常包括以下几项：员工离职后当天失去访问权限，新员工只能访问所需的一组主机而不是全部主机，以及三个月后仍能回答“谁在周二登录过那台主机”。请为这些需求排序。排序结果将决定工具选择。

有一项内容不在本文范围内。集中管理无法解决不安全的密钥管理；只要一把私钥泄露，下面三种方案都会失效。可靠的 SSH 密钥管理介绍密码短语、密钥类型和轮换。构建任何集中式方案前，应先完成这些基础工作。

方案一：每台主机上运行 SSSD 的目录服务

架构很简单。一台 LDAP 服务器即可；如果希望用户登录不受重启影响，也可以使用两台。用户信息存储在目录中。每台主机运行 SSSD。SSSD 接入 NSS（名称服务切换），使 id alice 能够解析；同时接入 PAM（可插拔认证模块），使身份验证正常工作。当 getent passwd alice 返回一个在 /etc/passwd 中没有对应条目的用户时，各组件便已连接起来。

截至 2026 年 8 月，实际可选方案如下：

• OpenLDAP：纯目录服务。您需要自行设计目录树、加载架构、配置 TLS（传输层安全）、编写访问控制列表并设置复制。OpenLDAP 2.6 Administrator's Guide 是参考文档；它篇幅很长是有原因的。
• FreeIPA：在一次安装中集成 389 Directory Server、MIT Kerberos、证书颁发机构、DNS 和基于主机的访问控制。它开箱即用地解决了更多问题。但它要求使用自身的 DNS 记录和稳定的完全限定域名，最适合 RHEL 系列系统。请参阅 freeipa.org。
• 带 LDAP 接口的 SSO（单点登录）产品。Authentik 的 LDAP provider 通过 LDAP 提供其用户数据库，并将 SSSD 作为客户端进行说明，因此 Web 应用和 shell 登录可以共用一份用户列表。Keycloak 是从现有 LDAP 目录联合用户身份，而不是提供 LDAP 目录；这一点容易令人误解。自托管 SSO 服务器的比较介绍了两者的区别，在自己的服务器上运行 Authentik介绍了部署方法。

有两个细节容易遗漏。第一，SSH 公钥可以存储在目录中：设置 ldap_user_ssh_public_key，并将 sshd 的 AuthorizedKeysCommand 指向 sss_ssh_authorizedkeys。如果跳过这一步，密码虽然实现了集中管理，密钥仍会分散在各个主目录中。第二，access_provider 的默认值是 permit，这意味着目录中的每个用户都可能登录加入该目录的每台主机。因此，加入一台新服务器会默默授予所有人 shell 访问权限，直到您设置实际的访问提供程序。

[domain/example.com]
cache_credentials = true
access_provider = simple
simple_allow_groups = linux-admins

[pam]
offline_credentials_expiration = 7

方案二：SSH 证书颁发机构

使用一个密钥对为证书签名。每台服务器通过 sshd_config 中的两行信任 CA 公钥。无需安装软件包、运行守护进程，也无需分发每个用户的文件。OpenSSH 从版本 5.4 起支持证书，因此当前发行版都已内置此功能。

TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

证书是关于公钥的签名声明。它包含用于标识人员的密钥 ID、主体列表（该密钥可用于登录的账户名称）、有效期，以及 force-command 或 source-address 等选项。每台主机上的 AuthorizedPrincipalsFile 决定哪些主体可以映射为哪些本地用户。因此，同一张证书可以在一台服务器上拥有管理员权限，在另一台服务器上则完全无权访问。围绕证书构建工具前，建议完整阅读 ssh-keygen 手册中的 CERTIFICATES 部分。

ssh-keygen -s /etc/ssh/user_ca -I alice@example.com -n deploy -V +8h -z 1042 id_ed25519.pub

其中最重要的选项是 -V。手册明确说明了默认行为：证书从 Unix 纪元起一直有效到遥远的未来。如果忘记设置 -V，就不是在签发一次登录权限，而是在签发一个永久凭据，任何服务器都不会停止信任它。使用 ssh-keygen -L -f id_ed25519-cert.pub 检查签名脚本实际生成的内容，并在信任该脚本前读取有效期一行。

也要为主机密钥签名。在每台服务器上配置 HostCertificate，并在本地 known_hosts 中添加一行 @cert-authority，即可消除以后构建的所有服务器上的“无法确认主机真实性”提示，也能避免形成不查看内容就输入 yes 的习惯。当您 管理的 Linux 服务器多到无法逐一说出名称 时，这种习惯才是真正的风险。

需要注意的是：证书只授权登录，不会创建 Unix 账户。本地账户必须已经存在，可以由配置管理系统或目录服务创建，也可以使用 deploy 这类共享角色账户，让多名人员切换为该账户。对于签名脚本以外的工具，HashiCorp Vault 的 signed SSH certificates 引擎和 step-ca 都可以在 SSO 登录后签发短期证书。

选项三：通过配置管理创建账户和密钥

Ansible、Salt 或 Puppet 创建账户，生成 authorized_keys，并在 /etc/sudoers.d 中写入文件。真实配置源是 Git 仓库。移除某人只需提交一次变更并执行一次运行。

不要把这视为入门选项。Git 历史记录可供审查，能够说明谁在何时授予了哪些权限，以及谁批准了这些变更；其他选项都不会自动提供这些信息。登录时不会执行任何操作，因此身份验证不依赖网络服务处于运行状态。小型团队经常忽视这一点，之后会为此付出代价。

它的弱点很明确，必须直接说明：配置正确性取决于最近一次运行是否到达主机。服务器如果已关机，或网络路径已损坏，就会继续保留刚刚删除的密钥；而该运行会将其报告为无法访问，而不是执行失败。因此，Ansible 处理无法访问主机的方式比表面上更重要。在执行离职清理时，无法访问的主机表示任务尚未完成，而不是可以略过的警告。

真正需要多长时间才能删除某个用户？

这三种方法都不会结束已经打开的会话。它们只能阻止用户进行下一次登录。若要结束当前访问，请使用 pkill -u alice 终止会话，或重启服务器。下文均基于这一前提。

目录服务理论上响应很快，但实际速度较慢，因为 SSSD 会缓存数据。entry_cache_timeout 的默认值为 5400 秒，因此组成员身份变更可能需要 90 分钟才能在主机上生效，除非运行 sss_cache -E。更严重的是，cache_credentials 会将用户的密码哈希存储在用户登录过的每台主机上，而 offline_credentials_expiration 的默认值为 0，表示不设限制。这两个默认值结合后，被禁用的用户仍可在缓存过其信息的任何主机上离线登录，且没有到期时间。请像上述配置中那样，将过期时间设置为天数。

SSH CA 理论上速度较慢，但实际操作更快。您不需要撤销证书，只需让证书过期。有效期为 8 小时的证书会在 8 小时内失效，无需联系任何主机，也不会遗漏任何主机。如果需要立即撤销访问权限，请使用 ssh-keygen -k 生成密钥吊销列表（KRL），将其分发到每台主机，并在 RevokedKeys 中指定该列表。这同样需要推送到每台主机，正是您原本希望避免的问题。因此，应将 KRL 作为紧急处理方式，而不是日常操作。

配置管理的速度取决于能够响应的主机，并与在这些主机上完成一次运行的时间相当。在规模较小的主机群中，通常只需几分钟。判断删除是否成功的关键不是运行耗时，而是有多少台主机无法访问。

中心服务无法访问时，哪些功能会中断？

这个问题决定小型服务器集群的方案，因此先回答它。

目录服务中断最危险。依赖目录服务查询用户的主机可能拒绝登录或导致登录停滞。由于所有主机都指向同一台服务器，它们会同时发生故障。一台损坏的虚拟机就可能立即阻塞所有主机的登录。因此，以下三项不可省略。设置 cache_credentials = true，这样以前登录过某台主机的用户可以在中断期间再次登录。运行第二台目录服务器，并在 ldap_uri 中列出两台服务器。每台主机都保留一个本地 break-glass 账户，并为该账户配置独立密钥。同时应掌握访问服务商控制台的方法，将其作为最后的恢复手段。

在依赖缓存前，必须了解它的限制。缓存按主机和用户分别保存。以前从未登录过某台主机的用户，在该主机上没有缓存记录。新建主机的缓存为空，因此目录服务中断时，最新部署的服务器反而无人能够登录。在主机上，sssctl domain-status 可报告 SSSD 当前是否认为域处于在线状态。

然后进行有意测试。在一台主机上使用防火墙规则阻断目录服务端口，同时保持第二个终端打开，并尝试登录。如果没有测试过缓存和 break-glass 账户，就无法确认它们确实可用。这与 例行 Linux 服务器维护检查清单 中的其他操作遵循相同原则：从未演练过的恢复路径，才是最容易失效的路径。

SSH CA 会平稳失效。签发服务停止后，无法获取新证书，但已经签发的证书在过期前仍可使用。人员通常会在下一个工作日开始时发现问题，而不是在事故处理中途发现。更严重的 CA 故障是另一种情况：CA 私钥等同于整个服务器集群的控制权，因此应将其离线保存、存放在硬件令牌中，或置于会记录每次签名操作的服务内。

配置管理服务不必持续在线。运行完成后，每台主机会完全独立地进行身份验证。

sudo 策略存放在哪里？

目录可以包含 sudo 规则。sudoers 条目可以存储在 LDAP 中，并通过 SSSD 的 sudo responder 读取，其中 sudoers: files sss 位于 /etc/nsswitch.conf 中。FreeIPA 将 sudo 规则视为一等对象。使用普通 OpenLDAP 时，需要加载 sudo schema，并手动编写 sudoRole 条目。许多团队即使完成了这些配置，仍会将 /etc/sudoers.d 保留在主机上，因为这样更易于读取，并且在服务中断期间仍可正常工作。

SSH 证书不包含任何权限信息。它授予主体以某个身份登录，之后的所有操作都遵循普通的本地 sudo 策略。如果希望由证书本身限制行为，可使用 force-command 和 source-address，但它们的控制能力有限。

配置管理工具会将模板写入 /etc/sudoers.d/，并使用 visudo -cf 验证后再安装。无论选择哪种身份管理方案，这一点都不会改变，因为 sudo 策略本质上按主机配置。在集中管理之前，先确定谁可以获得哪些权限：设计 VPS 上遵循最小权限原则的用户账户 是这三种工具都无法替您完成的工作。

之后能证明什么？

审计问题正是 SSH CA 明显占优的地方。当 sshd 接受证书时，它会在已接受的登录记录旁记录证书的密钥 ID 和序列号。因此，登录共享 deploy 账户时，主机自身的身份验证日志仍会记录实际登录者。共享账户不再是匿名的。使用 -z 签发序列号后，每张证书都能在之后单独识别，无论是在吊销列表中还是通过日志搜索。

目录服务会在自身日志中集中记录身份验证尝试，同时保留每台主机的 journal。它无法建立共享账户与具体人员之间的关联。

配置管理能最完整地记录授权，但对身份验证的记录最弱。Git 会准确记录谁在何时授予了访问权限。实际登录在 journalctl -u ssh 中仍然只是一个账户名。

这三种方式都依赖将日志发送到主机外部，因为主机上的 root 可以修改该主机的日志。只保存在被审计主机上的审计轨迹不能作为证据。

部署每种方案的成本

从零部署 OpenLDAP 通常需要数天，之后还要持续维护：模式、TLS 证书、访问控制列表、复制、目录备份、在每台主机上配置 SSSD，以及制定 SSH 密钥管理方案。若您已经使用 RHEL 系列系统并控制 DNS，FreeIPA 通常只需数小时即可部署；但对于少量小型 VPS 实例，它的配置和运行负担较重。若您已经将 Authentik 用于 Web 应用，使用其 LDAP 提供程序的成本较低；但您仍需处理 SSSD、服务中断时的访问问题，以及 sudo 权限管理问题。

SSH CA 的可用版本通常一个下午即可完成：生成 CA 密钥，在 sshd_config 中添加两行，为每台主机编写一个 principals 文件，并编写签名脚本。后续工作是保护 CA 密钥，并自动化证书签发，避免每天早上手动签名。Vault 和 step-ca 正是为解决这部分问题而设计的。

如果您已经在使用配置管理系统，配置这套方案大约需要1小时。如果还没有，您最终仍会需要它，因为它不仅可用于加固每台 VPS 上的 SSH，还可确保其他必须在各台主机之间保持一致的配置一致。

根据服务器规模选择方案

服务器数量在10台以内，管理员只有1到2人时，选择配置管理。没有集中式组件可发生故障，Git 是事实记录；由于您可以查看所有主机，凭据撤销延迟也会保持较短。对于这种规模，目录服务形成的单点故障更可能让您无法登录，而不是被攻击者攻破。将新 VPS 的前10分钟纳入同一个 playbook，即可让每台主机以一致的配置启动。

服务器数量在10到大约50台之间，管理员有多人且人员流动频繁时，选择 SSH 证书颁发机构。撤销会自动完成，不再需要手动处理；主机证书可以消除指纹确认提示；即使使用共享账户，也能保留按人员区分的审计记录；已经持有证书的用户不会因签名服务中断而受到影响。继续通过配置管理创建本地账户。这两种方案配合良好。

服务器规模更大时，或者同一批人员需要使用一个身份访问 Web 应用和 shell，或者加入和离职流程由其他团队负责时，选择目录服务。在这种规模下，目录服务的运维成本是合理的，因为您会运行副本并完成故障测试。若使用 RHEL 系列系统，可选择 FreeIPA；如果 Web 技术栈已经使用 LDAP provider，则可选择带 LDAP provider 的 SSO 产品。

有一种组合方案值得单独说明，因为大型环境实际采用的就是这种架构。目录服务负责账户、组和 sudo 规则。SSH CA 负责登录路径和审计记录。两者互不替代。无论选择哪种方案，都应保留本地 break-glass 账户，并保留经过测试的故障应急路径。

FAQ

是否需要 OpenLDAP 来集中管理 Linux 登录？

不需要。OpenLDAP 负责集中管理身份，而身份只是整体方案的一部分。如果目标是“删除一个人员后，让所有服务器都立即同步”，那么在小规模服务器群中，可以让配置管理系统写入 authorized_keys 和 /etc/sudoers.d，且不需要运行时依赖；也可以通过 SSH 证书颁发机构设置自动过期来实现。主机数量达到几十台、人员经常变动，或要求 shell 登录和 Web 应用共用同一用户列表时，目录服务才更值得投入。

LDAP 服务器宕机后，Linux 登录会发生什么？

使用该服务器查询用户信息的主机可能拒绝登录或长时间停滞。由于所有主机都指向同一台服务器，它们会同时发生故障。设置 cache_credentials = true 后，之前登录过该主机的用户可以使用本地缓存进行身份验证。但是，从未登录过该主机的用户，或在故障开始后才部署的主机，都没有可用缓存。运行第二台目录服务器，设置 cache_credentials 和合理的 offline_credentials_expiration，在每台主机上保留一个使用独立密钥的本地紧急账户，并在一台机器上阻断目录服务端口，验证整套机制是否正常。

如何通过证书颁发机构立即撤销 SSH 访问权限？

通常通过证书过期实现撤销：使用类似 -V +8h 的较短有效期签发证书，访问权限会自动结束。要立即撤销时，使用 ssh-keygen -k 创建密钥撤销列表，将其分发到每台主机，并在 sshd_config 中让 RevokedKeys 指向该列表。这需要推送到每台主机，因此应将其作为紧急处理路径。两种方法都不会终止已经建立的会话；必要时，使用 pkill -u alice 结束这些会话。

可以使用 Keycloak 或 Authentik 进行 Linux SSH 登录吗？

Authentik 可以，Keycloak 不能直接实现。Linux 身份验证通过 NSS 和 PAM 运行，而这两者使用 LDAP，不使用 OIDC（OpenID Connect）。Authentik 提供 LDAP provider，可通过 LDAP 提供其用户数据库，并将 SSSD 作为客户端，因此 Linux 主机可以像连接其他目录服务一样连接它。Keycloak 从现有 LDAP 目录进行联合，而不是提供目录服务，因此仍然需要目录服务。另一种方式是：用户完成 SSO 登录后，由 SSH 证书颁发机构签发短期证书；step-ca 及类似产品采用的就是这种方式。