User lookup via OpenSSH's AuthorizedPrincipalsCommand · Gitlab 中文文檔

# User lookup via OpenSSH's AuthorizedPrincipalsCommand > 原文：[https://docs.gitlab.com/ee/administration/operations/ssh_certificates.html](https://docs.gitlab.com/ee/administration/operations/ssh_certificates.html) * [Why use OpenSSH certificates?](#why-use-openssh-certificates) * [Setting up SSH certificate lookup via GitLab Shell](#setting-up-ssh-certificate-lookup-via-gitlab-shell) * [Principals and security](#principals-and-security) * [Interaction with the `authorized_keys` file](#interaction-with-the-authorized_keys-file) * [Other security caveats](#other-security-caveats) * [Disabling the global warning about users lacking SSH keys](#disabling-the-global-warning-about-users-lacking-ssh-keys) # User lookup via OpenSSH’s AuthorizedPrincipalsCommand[](#user-lookup-via-opensshs-authorizedprincipalscommand "Permalink") > [在](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19911) GitLab 社區版 11.2 中[可用](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19911) . GitLab 的默認 SSH 身份驗證要求用戶上載 SSH 公鑰，然后才能使用 SSH 傳輸. 在集中式（例如公司）環境中，這在操作上可能會很麻煩，特別是如果 SSH 密鑰是頒發給用戶的臨時密鑰，例如在發行后 24 小時過期的臨時密鑰. 在這種設置中，需要一些外部自動化過程來不斷將新密鑰上載到 GitLab. > **警告：需要** OpenSSH 6.9+版本，因為該版本引入了`AuthorizedPrincipalsCommand`配置選項. 如果使用 CentOS 6，則可以[按照以下說明](fast_ssh_key_lookup.html#compiling-a-custom-version-of-openssh-for-centos-6)來編譯最新版本. ## Why use OpenSSH certificates?[](#why-use-openssh-certificates "Permalink") 通過使用 OpenSSH 證書，有關 GitLab 上用戶擁有密鑰的所有信息都被編碼在密鑰本身中，并且 OpenSSH 自身保證用戶無法偽造此信息，因為他們需要訪問私有 CA 簽名密鑰. 正確設置后，就不需要完全將用戶 SSH 密鑰上傳到 GitLab. ## Setting up SSH certificate lookup via GitLab Shell[](#setting-up-ssh-certificate-lookup-via-gitlab-shell "Permalink") 如何完全設置 SSH 證書不在本文檔的范圍之內. 請參閱[OpenSSH 的`PROTOCOL.certkeys`](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)了解其工作方式，例如[RedHat 的文檔](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication) . 我們假設您已經設置了 SSH 證書，并且已經將 CA 的`TrustedUserCAKeys`添加到了`sshd_config` ，例如： ``` TrustedUserCAKeys /etc/security/mycompany_user_ca.pub ``` 通常，在這種設置中， `TrustedUserCAKeys`不會在" `Match User git`范圍內，因為它也將用于系統登錄到 GitLab 服務器本身，但是您的設置可能會有所不同. 如果 CA 僅用于 GitLab，請考慮將其放在" `Match User git`部分（如下所述）. 由該 CA 頒發的 SSH 證書**務必**具有與該用戶在 GitLab 上的用戶名相對應的"密鑰 ID"，例如（為簡潔起見，省略了一些輸出）： ``` $ ssh-add -L | grep cert | ssh-keygen -L -f - (stdin):1: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT SHA256:[...] Signing CA: RSA SHA256:[...] Key ID: "aearnfjord" Serial: 8289829611021396489 Valid: from 2018-07-18T09:49:00 to 2018-07-19T09:50:34 Principals: sshUsers [...] [...] ``` 從技術上講，這不是完全正確，例如，它可以`prod-aearnfjord`如果它是你通常會登錄到服務器作為一個 SSH 證書`prod-aearnfjord`用戶，但你必須指定自己的`AuthorizedPrincipalsCommand`做映射，而不是使用我們提供的默認. 重要的是， `AuthorizedPrincipalsCommand`必須能夠以某種方式從"密鑰 ID"映射到 GitLab 用戶名，我們提供的默認命令假設兩者之間存在 1 = 1 的映射，因為這樣做的重點是允許我們從密鑰本身提取 GitLab 用戶名，而不是依賴默認的公共密鑰到用戶名的映射. 然后，在您的`sshd_config`為`git`用戶設置`AuthorizedPrincipalsCommand` . 希望您可以使用 GitLab 隨附的默認值： ``` Match User git AuthorizedPrincipalsCommandUser root AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers ``` 該命令將發出類似于以下內容的輸出： ``` command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell username-{KEY_ID}",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty {PRINCIPAL} ``` 其中`{KEY_ID}`是傳遞給腳本的`%i`參數（例如`aeanfjord` ），而`{PRINCIPAL}`是傳遞給腳本的主體（例如`sshUsers` ）. 您將需要自定義其中的`sshUsers`部分. 對于可以登錄到 GitLab 的所有用戶，它應該是一定要保證是密鑰的一部分的主體，或者您必須提供一個主體列表，其中一個將提供給用戶，例如： ``` [...] AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers windowsUsers ``` ## Principals and security[](#principals-and-security "Permalink") 您可以根據需要提供任意數量的委托人，這些委托人將變成多行`authorized_keys`輸出，如`sshd_config(5)`中的`AuthorizedPrincipalsFile`文檔中所述. 通常，將`AuthorizedKeysCommand`與 OpenSSH 一起使用時，主體是允許登錄到該服務器的某個"組". 但是，在 GitLab 中，它僅用于滿足 OpenSSH 的要求，我們實際上只關心"密鑰 ID"的正確性. 一旦解壓縮，GitLab 將為該用戶強制執行自己的 ACL（例如，用戶可以訪問哪些項目）. 因此，例如對用戶接受的內容過分慷慨是可以的，因為如果用戶（例如）根本無法訪問 GitLab，它只會出錯并顯示一條有關該用戶無效的消息. ## Interaction with the `authorized_keys` file[](#interaction-with-the-authorized_keys-file "Permalink") SSH 證書可以與`authorized_keys`文件結合使用，并且如果按照上述`authorized_keys`文件的配置進行設置，它仍將作為后備. 這是因為，如果`AuthorizedPrincipalsCommand`無法對用戶進行身份驗證，則 OpenSSH 將回退到`~/.ssh/authorized_keys` （或`AuthorizedKeysCommand` ）上. 因此，仍然有理由結合使用["在數據庫中快速查找授權的 SSH 密鑰"](fast_ssh_key_lookup.html)方法. 由于您將對所有普通用戶使用 SSH 證書，并且如果使用密鑰，則依靠`~/.ssh/authorized_keys`后備來部署密鑰. 但是您可能會發現沒有必要這樣做，因為所有普通用戶都將使用快速的`AuthorizedPrincipalsCommand`路徑，并且只有自動部署密鑰訪問才會落在`~/.ssh/authorized_keys` ，或者您還有更多的密鑰可以使用普通用戶（尤其是續訂的用戶）比您擁有的部署密鑰. ## Other security caveats[](#other-security-caveats "Permalink") 用戶仍然可以通過手動將 SSH 公鑰上載到他們的配置文件中來繞過 SSH 證書身份驗證，依靠`~/.ssh/authorized_keys`后備來對其進行身份驗證. 當前沒有阻止它的功能， [但是有一個添加它的公開請求](https://gitlab.com/gitlab-org/gitlab/-/issues/23260) . 當前，可以通過提供一個自定義的`AuthorizedKeysCommand`來破解這種限制，該命令可檢查從`gitlab-shell-authorized-keys-check`返回的已發現密鑰 ID `gitlab-shell-authorized-keys-check`為部署密鑰（應拒絕所有非部署密鑰）. ## Disabling the global warning about users lacking SSH keys[](#disabling-the-global-warning-about-users-lacking-ssh-keys "Permalink") 默認情況下，GitLab 將向尚未將 SSH 密鑰上載到其配置文件的用戶顯示"您將無法通過 SSH 推送或推送項目代碼"警告. This is counterproductive when using SSH certificates, since users aren’t expected to upload their own keys. 要全局禁用此警告，請轉到"應用程序設置->帳戶和限制設置"，然后禁用"顯示用戶添加 SSH 密鑰消息"設置. This setting was added specifically for use with SSH certificates, but can be turned off without using them if you’d like to hide the warning for some other reason.