- OpenSSH 인증서 사용 이유
- GitLab Shell을 통한 SSH 인증서 조회 설정
- 주체 및 보안
authorized_keys파일과의 상호작용- 다른 보안 주의사항
- SSH 키가 없는 사용자에 대한 전역 경고 비활성화
OpenSSH의 AuthorizedPrincipalsCommand를 사용한 사용자 조회
기본 SSH 인증 방식인 GitLab에는 사용자가 SSH 전송을 사용하기 전에 SSH 공개 키를 업로드해야 합니다.
중앙집중식(예: 기업) 환경에서는 특히 임시 키(발급 후 24시간 후에 만료되는 키를 포함)를 사용하는 경우 이는 운영적으로 불편할 수 있습니다.
이러한 설정에서는 외부 자동화된 프로세스가 GitLab에 계속해서 새 키를 업로드할 수 있도록 필요합니다.
AuthorizedKeysCommand가 지문을 받아들일 수 있어야 하므로 OpenSSH 버전 6.9+가 필요합니다. 서버의 OpenSSH 버전을 확인하세요.OpenSSH 인증서 사용 이유
OpenSSH 인증서를 사용하면 GitLab 사용자에 대한 모든 정보가 키 자체에 인코딩되며, OpenSSH 자체가 사용자가 이를 위조할 수 없도록 보장합니다. 이를 올바르게 설정하면 사용자 SSH 키를 GitLab에 전혀 업로드할 필요가 없어집니다.
GitLab Shell을 통한 SSH 인증서 조회 설정
SSH 인증서를 완전히 설정하는 방법은 본 문서의 범위를 벗어납니다. 예를 들어 RedHat의 문서에서 작동 방법을 볼 수 있습니다.
이미 SSH 인증서를 설정하고 sshd_config에 CA의 TrustedUserCAKeys를 추가했다고 가정합니다. 예를 들어:
TrustedUserCAKeys /etc/security/mycompany_user_ca.pub
일반적으로 이러한 설정에서 이러한 TrustedUserCAKeys는 Match User git 아래에 범위가 지정되지 않을 것입니다. 이는 GitLab 서버 자체에 대한 시스템 로그인에도 사용되므로 Match User git 섹션에 이를 넣을 수 있지만 설정이 달라질 수 있습니다. 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가 될 수도 있습니다. 이 경우 prod-aearnfjord 사용자로 서버에 로그인하는 SSH 인증서일 경우, 사용자 고유의 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 부분을 사용자가 모두 가질 수 있는 주체 중 하나를 제공하거나 해당 사용자의 디렉터리을 제공해야 합니다. 예를 들어:
...
AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers windowsUsers
주체 및 보안
원하는 만큼 많은 주체를 제공할 수 있으며, 이러한 주체는 sshd_config(5)의 AuthorizedPrincipalsFile 문서에서 설명한대로 여러 개의 authorized_keys 출력 라인으로 변환됩니다.
일반적으로 OpenSSH와 함께 AuthorizedKeysCommand를 사용할 때 주체는 해당 서버에 로그인할 수 있는 “그룹”입니다. 그러나 GitLab의 경우 이것은 OpenSSH의 요구를 만족시키기 위해 사용될 뿐, 사실상 “키 ID”가 올바른지 확인하는 것만 신경쓰게 됩니다. 일단 이것이 추출되면 GitLab은 해당 사용자의 ACL을 강제합니다(예: 사용자가 액세스할 수 있는 프로젝트).
따라서 받아들일 때 관대한 것이 괜찮습니다. 예를 들어, 사용자가 GitLab에 액세스할 수 없다면, 해당 사용자가 유효하지 않은 사용자에 대한 메시지가 표시됩니다.
authorized_keys 파일과의 상호작용
SSH 인증서는 authorized_keys 파일과 함께 사용할 수 있으며, 위에서 구성한 대로 AuthorizedPrincipalsCommand를 사용하면 여전히 authorized_keys 파일이 대안으로 작동합니다.
이는 AuthorizedPrincipalsCommand가 사용자를 인증할 수 없는 경우에 대비한 것입니다. OpenSSH는(또는 AuthorizedKeysCommand)의 대체로 ~/.ssh/authorized_keys로 되돌아갑니다.
따라서 데이터베이스에서 인증된 SSH 키의 빠른 조회 방법과 함께 사용할 경우에도 이 방법을 사용하는 이유가 있을 수 있습니다. 일반적인 사용자의 SSH 인증서는 사용하지만, ~/.ssh/authorized_keys를 사용하는 자동화 배포 키에 의존하는 경우에는 특히 그렇습니다.
그러나 모든 것이 일반적인 사용자가 빠른 AuthorizedPrincipalsCommand 경로를 사용하고, 자동화된 배포 키가 ~/.ssh/authorized_keys로 되돌아가는 경우만 사용한다면, 이것을 사용할 이유가 없을 수 있습니다. 또는 일반적인 사용자(특히 갱신되는 경우)의 키가 자동 배포 키보다 훨씬 많을 경우에는 더 많은 키가 있으므로 그렇게 할 필요가 없을 수 있습니다.
다른 보안 주의사항
사용자는 여전히 SSH 인증서 인증을 우회하여 자신의 프로필에 SSH 공개 키를 매뉴얼으로 업로드함으로써 인증할 수 있습니다. 현재 이를 방지하는 기능은 없습니다. 하지만 이에 대한 오픈 요청이 있습니다.
예를 들어, gitlab-shell-authorized-keys-check에서 가져온 발견된 키 ID가 배포 키인지 여부를 확인하는 사용자 정의 AuthorizedKeysCommand를 제공함으로써 현재 이 제한을 해킹할 수 있습니다.
SSH 키가 없는 사용자에 대한 전역 경고 비활성화
기본적으로 GitLab은 프로필에 SSH 키를 업로드하지 않은 사용자에게 “SSH를 통한 프로젝트 코드 풀이나 푸시가 불가능합니다.” 경고 메시지를 표시합니다.
이는 SSH 인증서를 사용할 때 역효과적이며, 사용자가 자신의 키를 업로드하지 않을 것으로 예상되지 않습니다.
전역적으로 이 경고를 비활성화하려면 “애플리케이션 설정 -> 계정 및 제한 설정”으로 이동하여 “사용자 SSH 키 추가 메시지 표시” 설정을 비활성화하세요.
이 설정은 목적에 맞추어 추가되었지만, 이를 사용하지 않은 경우에도 경고를 숨기고 싶다면 이 설정을 비활성화할 수 있습니다.
도움말