- OpenSSH 인증서를 사용하는 이유는 무엇인가요?
- GitLab Shell을 통한 SSH 인증서 조회 설정
- 원칙 및 보안
authorized_keys
파일과의 상호작용- 기타 보안 주의 사항
- SSH 키가 없는 사용자에 대한 전역 경고 비활성화
OpenSSH의 AuthorizedPrincipalsCommand를 통한 사용자 조회
GitLab의 기본 SSH 인증은 사용자가 SSH 전송을 사용하기 전에 SSH 공개 키를 업로드해야 합니다.
중앙 집중식(예: 기업) 환경에서는 SSH 키가 사용자에게 발급된 임시 키인 경우, 특히 발급 후 24시간 후에 만료되는 경우 운영적으로 번거로울 수 있습니다.
이러한 설정에서는 GitLab에 새로운 키를 지속적으로 업로드하기 위한 외부 자동화 프로세스가 필요합니다.
AuthorizedKeysCommand
가 지문을 수용할 수 있어야 하므로 OpenSSH 버전 6.9+가 필요합니다. 서버에서 OpenSSH의 버전을 확인하세요.OpenSSH 인증서를 사용하는 이유는 무엇인가요?
OpenSSH 인증서를 사용하면 GitLab에서 어떤 사용자가 키를 소유하는지에 대한 모든 정보가 키 자체에 인코딩되며, OpenSSH는 사용자가 이를 위조할 수 없도록 보장합니다. 이는 사용자가 개인 CA 서명 키에 접근할 수 있어야 하기 때문입니다.
올바르게 설정하면 사용자의 SSH 키를 GitLab에 업로드할 필요가 완전히 없어집니다.
GitLab Shell을 통한 SSH 인증서 조회 설정
SSH 인증서를 완전히 설정하는 방법은 이 문서의 범위를 벗어납니다. 작동 방법은
OpenSSH의 PROTOCOL.certkeys
를 참조하세요. 예를 들어
RedHat의 문서를 참고하세요.
이미 SSH 인증서를 설정하고 CA의 TrustedUserCAKeys
를 sshd_config
에 추가했다고 가정합니다. 예:
TrustedUserCAKeys /etc/security/mycompany_user_ca.pub
보통 TrustedUserCAKeys
는 이러한 설정에서 Match User git
하에 범위가 지정되지 않지만 시스템 로그인이 GitLab 서버 자체에 사용되므로 귀하의 설정은 다를 수 있습니다. CA가 GitLab에만 사용되는 경우, 아래 설명된 대로 Match User git
섹션에 이를 두는 것을 고려하세요.
해당 CA에서 발급된 SSH 인증서 must는 해당 사용자의 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 인증서일 경우, 사용자 자신의 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
원칙 및 보안
원하는만큼 많은 원칙을 제공할 수 있으며, 이는 authorized_keys
출력의 여러 줄로 변환됩니다. 이는 sshd_config(5)
의 AuthorizedPrincipalsFile
문서에 설명되어 있습니다.
일반적으로 OpenSSH와 함께 AuthorizedKeysCommand
를 사용할 때 원칙은 해당 서버에 로그인할 수 있는 “그룹”입니다. 그러나 GitLab에서는 OpenSSH의 요구사항을 충족시키기 위해서만 사용되며, 실제로는 “키 ID”가 정확한지 여부만 신경 씁니다. 일단 이 정보가 추출되면 GitLab은 해당 사용자의 자체 ACL을 강제합니다 (예: 사용자가 접근할 수 있는 프로젝트).
따라서 수용하는 데 있어 지나치게 관대한 것은 괜찮습니다. 예를 들어, 사용자가 GitLab에 접근할 수 없는 경우, 잘못된 사용자에 대한 메시지와 함께 오류가 발생합니다.
authorized_keys
파일과의 상호작용
위에서 설명한 대로 SSH 인증서가 설정된 경우, 이는 authorized_keys
파일과 함께 사용될 수 있어 authorized_keys
파일이 대체로 사용될 수 있습니다.
만약 AuthorizedPrincipalsCommand
가 사용자를 인증할 수 없는 경우, OpenSSH는 ~/.ssh/authorized_keys
파일을 확인하거나 AuthorizedKeysCommand
를 사용하도록 되돌립니다. 따라서 SSH 인증서와 함께 SSH 키의 빠른 조회를 여전히 사용할 필요가 있을 수 있습니다.
대부분의 사용자에게, SSH 인증서는 AuthorizedPrincipalsCommand
를 사용하여 인증을 처리하며, ~/.ssh/authorized_keys
파일은 주로 배포 키와 같은 특정 경우에 대한 대체 수단으로 사용됩니다. 그러나 설정에 따라, 일반 사용자에게 AuthorizedPrincipalsCommand
만 사용하는 것이 충분할 수 있습니다. 이런 경우, authorized_keys
파일은 자동 배포 키 접근이나 기타 특정 시나리오에만 필요합니다.
일반 사용자(특히 자주 갱신되는 경우)의 키 수와 배포 키 간의 균형을 고려하여 authorized_keys
대체 수단을 유지해야 하는지 여부를 결정하세요.
기타 보안 주의 사항
사용자는 여전히 SSH 인증서를 우회하여 SSH 공개 키를 프로필에 수동으로 업로드하고 ~/.ssh/authorized_keys
대체 수단에 의존하여 이를 인증할 수 있습니다.
사용자가 배포 키가 아닌 SSH 키를 업로드하지 못하도록 방지하는 설정을 추가하기 위한 오픈 이슈가 있습니다.
이 제한을 강제하는 체크를 직접 작성할 수 있습니다. 예를 들어, 발견된 키 ID가 gitlab-shell-authorized-keys-check
에서 반환된 것이 배포 키인지 아닌지를 확인하는 사용자 정의 AuthorizedKeysCommand
를 제공하세요 (모든 비배포 키는 거부해야 합니다).
SSH 키가 없는 사용자에 대한 전역 경고 비활성화
기본적으로 GitLab은 프로필에 SSH 키를 업로드하지 않은 사용자에게 “SSH를 통해 프로젝트 코드를 끌어오거나 푸시할 수 없습니다”라는 경고를 표시합니다.
이는 SSH 인증서를 사용할 때 비생산적입니다. 사용자들은 자신의 키를 업로드할 것으로 예상되지 않기 때문입니다.
이 경고를 전역적으로 비활성화하려면 “응용 프로그램 설정 -> 계정 및 제한 설정”으로 이동하여 “SSH 키 추가 사용자 메시지 표시” 설정을 비활성화하세요.
이 설정은 SSH 인증서와 함께 사용하기 위해 특별히 추가되었지만, 다른 이유로 경고를 숨기고 싶다면 사용하지 않고도 끌 수 있습니다.