Linux 集中登入：LDAP、SSH CA 怎麼選？

集中 Linux 登入真正要解決的問題

多數開始集中管理 Linux 登入的管理者，想要的其實只有一件事：只建立一次使用者、只移除一次使用者，讓所有伺服器都採用相同狀態。目錄服務可以做到這點。但在由 6 個 VPS 執行個體組成的伺服器群組中，這也是最脆弱的做法，因為目錄服務一旦無法連線，可能同時拒絕所有機器上的登入。

有 3 種做法可以實現「修改一次，所有主機都遵循」。你可以執行 OpenLDAP 或 FreeIPA 等目錄服務，並在每台主機上使用 SSSD（system security services daemon）。你也可以從自己的憑證授權單位（CA）簽發短效期 SSH 憑證。另一種做法是透過組態管理系統寫入使用者帳號與 authorized_keys 檔案。本文會依撤銷速度、服務中斷期間的行為、sudo 政策、稽核軌跡與設定成本，評估這 3 種做法，最後依伺服器群組規模提出建議，而不是指定單一最佳方案。

安裝 OpenLDAP 前，先檢視前提是否成立

LDAP（輕量級目錄存取協定）會集中管理身分資訊：使用者名稱、數值使用者 ID、群組成員資格，以及通常包含密碼。這是它的核心用途。它也能分發 SSH 公開金鑰，並保存哪些使用者可執行 sudo 的規則；但這兩項功能都必須先完成設定：金鑰需要 sshPublicKey 屬性，並在 sshd 後方設定 sss_ssh_authorizedkeys；sudo 規則則需要載入 sudo schema，且每台主機都要設定 sudo provider。LDAP 不會記錄誰從哪裡登入。這些都是另外疊加的獨立設定。團隊安裝 OpenLDAP 時，常以為它是完整的存取控制系統，最後得到的卻是一個需要維護 schema、存取控制語法與複寫拓撲的資料庫。

因此，選擇工具前，先寫下真正的需求。通常包括以下幾項：離職人員在同一天失去存取權；新進人員取得正確主機子集的存取權，而不是所有主機的存取權；以及在 3 個月後仍能回答「誰在星期二登入那台主機」。請為這些需求排序。排序結果會決定工具。

有一點不在本文範圍內。集中管理無法修正不良的金鑰管理方式，而任何一把洩漏的私密金鑰都能使下列 3 個選項失去作用。完善的 SSH 金鑰管理涵蓋密碼片語、金鑰類型與輪替；在此基礎上建置任何集中式方案前，應先完成這些準備工作。

選項一：每台主機都使用 SSSD 連線至目錄服務

架構很簡單。一台 LDAP 伺服器即可；若希望重新開機後仍能登入，也可以使用兩台。使用者帳戶儲存在其中。每台主機都執行 SSSD。SSSD 會接入 NSS（name service switch），讓 id alice 能夠解析；也會接入 PAM（pluggable authentication modules），讓驗證正常運作。當 getent passwd alice 回傳某位使用者，而該使用者在 /etc/passwd 中沒有對應項目時，這些元件便已連接完成。

截至 October 2026，實際可行的選擇如下：

• OpenLDAP：基本的目錄服務。您必須自行設計樹狀結構、載入 schema、設定 TLS（transport layer security）、撰寫存取控制清單，並設定複寫。OpenLDAP 2.6 Administrator's Guide 說明長期支援系列，2.7 guide 則說明較新的功能版本。兩份指南都很長，原因就在於此。
• FreeIPA：在單一安裝中整合 389 Directory Server、MIT Kerberos、憑證授權單位、DNS 及以主機為基礎的存取控制。它能直接處理更多設定。FreeIPA 也要求使用自己的 DNS 記錄及穩定的完整網域名稱主機名稱，而且最適合部署在 RHEL 系列系統。請參閱 freeipa.org。
• 具備 LDAP 介面的 SSO（single sign-on）產品。Authentik 的 LDAP provider 會透過 LDAP 提供其使用者資料庫，並說明如何以 SSSD 作為用戶端，因此 Web 應用程式與 shell 登入可以共用同一份使用者清單。Keycloak 會從現有的 LDAP 目錄進行聯邦，而不是提供 LDAP 目錄；這項差異常令人意外。自架 SSO 伺服器的比較 說明兩者的差異，在自己的伺服器上執行 Authentik 則說明部署方式。

有兩個部分很容易漏掉。第一，SSH 公開金鑰可以儲存在目錄中：將金鑰存入 sshPublicKey 屬性。這是 SSSD 的 ldap_user_ssh_public_key 預設讀取的屬性；只有在您的 schema 使用其他名稱時，才需要設定該選項。接著將 sshd 的 AuthorizedKeysCommand 指向 /usr/bin/sss_ssh_authorizedkeys，並搭配 AuthorizedKeysCommandUser nobody。若略過這項設定，密碼雖已集中管理，金鑰仍會分散在各個家目錄中。第二，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 公開金鑰。不需要安裝套件、不需要執行 daemon，也不需要推送每位使用者各自的檔案。OpenSSH 從 version 5.4 開始支援憑證，因此目前的各 Linux distribution 都已具備這項功能。

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

憑證是針對公開金鑰所簽署的聲明。憑證包含識別人員的 key ID、可用該金鑰登入的帳號名稱清單（principals）、有效期限，以及 force-command 或 source-address 等選項。每台主機的 AuthorizedPrincipalsFile 決定哪些 principals 可以對應到哪些本機使用者，因此同一張憑證在一台主機上可以是管理員，在另一台主機上則完全沒有權限。開始建立相關工具前，建議完整閱讀 ssh-keygen 手冊的 CERTIFICATES 章節。

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

其中最重要的 flag 是 -V。手冊明確說明了預設值：憑證的有效期間從 Unix epoch 一直延續到遙遠的未來。忘記 -V 就不是簽發一次登入權限，而是簽發一組任何伺服器永遠不會停止信任的永久憑證。請使用 ssh-keygen -L -f id_ed25519-cert.pub 檢查簽署 script 實際產生的內容，並在信任該 script 前讀取有效期限。

主機金鑰也應簽署。在每台伺服器設定 HostCertificate，並在本機 known_hosts 加入一行 @cert-authority，即可移除日後每台新建伺服器出現的「無法建立主機真實性」提示，也能避免形成未檢查就輸入 yes 的習慣。當你 管理的 Linux 伺服器多到無法逐一說出名稱 時，這個習慣才是真正的風險。

但有一點很重要：憑證只會授權登入，不會建立 Unix 帳號。本機帳號必須事先存在，可以由組態管理工具、directory 建立，或使用 deploy 這類共享角色帳號，讓多位人員都能切換成該帳號。若需要簽署 script 以外的工具，HashiCorp Vault 的 signed SSH certificates engine 與 step-ca 都能在 SSO 登入後簽發短效憑證。

選項三：透過設定管理系統管理帳戶與金鑰

Ansible、Salt 或 Puppet 會建立帳戶、產生 authorized_keys，並在 /etc/sudoers.d 中放置檔案。Git repository 是唯一可信來源。移除人員只需建立一次 commit 並執行一次套用作業。

不要將這視為初學者選項。Git 歷程是可供審查的紀錄，能顯示誰在何時授予哪些權限，以及由誰核准。其他選項都不會免費提供這項能力。登入時不會執行任何操作，因此驗證不會依賴網路服務是否正常運作。小型團隊經常忽略這點，之後便會後悔。

它的弱點很明確，必須直接說明：正確性取決於上一次執行是否已連線到主機。已關機或網路路徑故障的伺服器，仍會保留你剛刪除的金鑰；而該次執行會將主機回報為無法連線，而不是執行失敗。這就是為什麼Ansible 處理無法連線主機的方式比乍看之下更重要。在撤銷人員存取權的執行作業中，無法連線的主機代表尚未完成的工作，不是可以略過的警告。

實際上要多久才能移除某位使用者？

這 3 種方式都不會終止已經建立的工作階段。它們只會阻止下一次登入。若要結束目前的存取權，請使用 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 視為緊急處理方式，而不是例行方式。

組態管理的速度取決於能回應的主機完成一次執行所需的時間。小型主機群通常只需幾分鐘。判斷移除是否成功的，不是執行時間，而是無法連線的主機數量。

中心服務無法連線時會發生什麼問題？

這個問題會決定小型主機群組的架構選擇，因此先回答。

目錄服務中斷最危險。依賴目錄服務查詢使用者的主機可能拒絕登入或讓登入程序停滯。由於所有主機都指向同一台伺服器，會同時故障。一台損壞的虛擬機器就可能讓所有主機的登入同時受阻。因此，以下3項都不可省略。設定 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。sudo 發行版本提供 OpenLDAP 的 sudoers schema 檔案（包括適用於 cn=config 線上設定的版本）、Active Directory 和 389 Directory Server 等。FreeIPA 將 sudo 規則視為一級物件。使用一般 OpenLDAP 時，您必須載入 sudo schema，並手動撰寫 sudoRole 項目。許多團隊即使完成這些設定，仍會在主機上保留 /etc/sudoers.d，因為這樣較容易讀取，服務中斷時也能繼續運作。

SSH 憑證不會說明權限。它只會授予某個 principal 登入權限，之後的所有行為都由一般的本機 sudo 政策處理。若要讓憑證本身限制行為，可使用 force-command 和 source-address，但這兩項工具的限制都很粗略。

設定管理工具會將範本寫入 /etc/sudoers.d/，並在安裝前使用 visudo -cf 驗證。無論您選擇哪種 identity 方案，這點都不會改變，因為 sudo 政策本質上是以主機為單位。集中化之前，先決定誰能取得哪些權限：設計 VPS 上的最小權限使用者帳戶 是這 3 種工具都無法代勞的工作。

事後能證明什麼？

稽核問題正是 SSH CA 明顯具備優勢的地方。sshd 接受憑證時，會在成功接受的登入旁記錄憑證的 key ID 與序號。因此，即使登入的是共用的 deploy 帳號，主機自己的驗證日誌仍會記錄實際登入者。共用帳號不再代表匿名登入。使用 -z 核發序號後，每張憑證日後都能在撤銷清單或日誌搜尋中個別識別。

目錄服務會在自身日誌中集中記錄驗證嘗試，另外也會留下每台主機的 journal。但它無法建立共用帳號與特定人員之間的關聯。

設定管理能提供最完整的授權紀錄，但驗證紀錄最弱。Git 會明確記錄誰在何時授予存取權。實際登入在 journalctl -u ssh 中仍只會顯示帳號名稱。

這 3 種方式都必須將日誌送出主機，因為主機上的 root 可以修改該主機的日誌。只存在於受稽核主機上的稽核軌跡，不能作為證據。

建置各項方案的成本

OpenLDAP 從零開始建置通常需要數天，後續還要持續維護：schema、TLS 憑證、存取控制清單、複寫、目錄備份、在每台主機上設定 SSSD，以及規劃 SSH keys。若您已使用 RHEL 系列，且 DNS 已受到妥善管理，FreeIPA 約需數小時即可完成；但對少量的小型 VPS instance 而言，FreeIPA 的架構過於龐大。若您已使用 Authentik 處理 Web application，搭配 LDAP provider 的 Authentik 建置成本很低；不過 SSSD、服務中斷時的處理方式，以及 sudo 的管理問題仍須自行處理。

SSH CA 的可用版本約一個下午即可完成：產生 CA key、在 sshd_config 加入兩行設定、為每台主機建立一個 principals 檔案，並撰寫簽署 script。後續工作是保護 CA key，並自動化憑證簽發，避免每天早上手動簽署憑證。Vault 和 step-ca 的用途就是解決這部分。

如果您已在使用 configuration management，設定約需一小時。若尚未使用，您仍會需要它，因為除了強化每台 VPS 的 SSH 設定之外，還有許多設定必須在各主機間保持一致。

適合您環境規模的方案

伺服器數量少於約 10 台，且由 1 或 2 名管理員負責時，採用組態管理。環境中沒有任何集中式元件可能故障，git 是記錄來源；由於您能查看所有主機，撤銷憑證的時間差也能維持在很短的範圍。此規模採用目錄服務，反而會建立單一故障點；它導致您被鎖在系統外的機率，遠高於攻擊者成功入侵的機率。將新 VPS 的前 10 分鐘納入同一份 playbook，所有主機就能以一致的方式啟動。

伺服器數量介於 10 至約 50 台，由多人管理，且人員異動頻繁時，採用 SSH 憑證授權中心。撤銷憑證會自動完成，不再是繁瑣的工作；主機憑證可消除指紋提示；即使共用帳號，仍能保留個人層級的稽核紀錄；已持有憑證的人員也不會因簽署服務中斷而受到影響。請繼續使用組態管理建立本機帳號。兩者搭配良好。

規模更大時，或同一批人員需要以一個身分登入 Web 應用程式與 shell，或加入與離職流程由其他單位負責時，採用目錄服務。此規模下，營運成本已值得投入；由於您會執行複本並測試複本，故障模式也能受到控制。如果使用 RHEL 系列，選擇 FreeIPA；如果 Web stack 已使用 LDAP provider，則選擇具備 LDAP provider 的 SSO 產品。

有一種搭配方式值得另列一行，因為大型環境實際上就是這樣運作。目錄服務管理帳號、群組與 sudo 規則。SSH CA 管理登入路徑與稽核軌跡。兩者互不取代。無論選擇哪一種方案，本機 break-glass 帳號與經測試的服務中斷處理路徑都必須保留。

FAQ

是否需要 OpenLDAP 來集中管理 Linux 登入？

不需要。OpenLDAP 可集中管理身分，但身分只是需求的一部分。如果目標是「移除某位人員後，所有伺服器都能同步反映」，小型伺服器環境可讓組態管理工具寫入 authorized_keys 和 /etc/sudoers.d，不需要執行期間的相依性；也可以使用 SSH 憑證授權單位，透過自動到期控管存取權。當您有數十台主機、經常有人員異動，或要求 shell 登入與 Web 應用程式共用同一份使用者清單時，導入目錄服務才值得其成本。

LDAP 伺服器停止運作時，Linux 登入會發生什麼事？

使用 LDAP 查詢使用者的主機可能拒絕登入，或讓登入程序停滯。由於所有主機都指向同一台伺服器，因此可能同時失效。設定 cache_credentials = true 後，先前曾在該主機登入的人員可以從本機快取進行驗證；但從未登入該主機的使用者，或在中斷開始後才建立的主機，都沒有可用的快取資料。請執行第二台目錄伺服器，使用合理的 offline_credentials_expiration 設定 cache_credentials，在每台主機保留一個使用獨立金鑰的本機緊急帳號，並在其中一台機器封鎖目錄服務連接埠，藉此測試整套機制。

如何透過憑證授權單位立即撤銷 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 目錄聯合驗證，而不是提供 LDAP 目錄，因此仍然需要目錄服務。另一種方式是使用 SSH 憑證授權單位，在 SSO 登入後簽署短效憑證；step-ca 及類似產品採用的就是這種方式。