데이터베이스에서 SSH 키를 빠르게 조회하기

Tier: Free, Premium, Ultimate Offering: Self-Managed
note
이 문서는 authorized_keys 파일의 드랍인 대체 방법을 설명합니다. 표준(배포 키가 아닌) 사용자의 경우 SSH 인증서를 사용하는 것을 고려해보세요. 이들은 더 빠르지만 드랍인 대체 방법은 아닙니다.

일반 SSH 작업은 사용자 수가 증가함에 따라 느려지게 됩니다. 왜냐하면 OpenSSH는 사용자를 승인하기 위해 키를 선형 검색하기 때문입니다. 사용자가 GitLab에 액세스할 수 있는 권한이 없는 경우와 같은 최악의 경우에는 OpenSSH가 전체 파일을 스캔하여 키를 찾습니다. 이는 상당한 시간과 디스크 I/O가 걸리며, 리파지토리로 푸시 또는 풀을 시도하는 사용자들에게 지연을 초래합니다. 더욱 나빠지는 점은 사용자가 자주 키를 추가하거나 제거하면 운영 체제가 authorized_keys 파일을 캐시할 수 없을 수 있으며, 이는 디스크에 반복적으로 액세스되어야 함을 의미합니다.

GitLab 셸은 GitLab 데이터베이스에서 빠르고 색인된 조회를 통해 SSH 사용자에게 인가하는 방법을 제공하여 이 문제를 해결합니다. 이 페이지에서는 인가된 SSH 키의 빠른 조회를 활성화하는 방법에 대해 설명합니다.

Geo에서 빠른 조회가 필요합니다

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

Cloud Native GitLab와는 달리, 기본적으로 Linux 패키지 설치는 git 사용자의 홈 디렉터리에 위치한 authorized_keys 파일을 관리합니다. 대부분의 설치에서 이 파일은 /var/opt/gitlab/.ssh/authorized_keys 아래에 위치하지만 다음 명령어를 사용하여 시스템에서 authorized_keys를 찾을 수 있습니다: 

getent passwd git | cut -d: -f6 | awk '{print $1"/.ssh/authorized_keys"}'

authorized_keys 파일에는 GitLab에 액세스할 수 있는 모든 사용자의 공개 SSH 키가 포함되어 있습니다. 그러나 Geo는 하나의 진실된 소스를 유지하기 위해 SSH 지문 조회를 데이터베이스 조회를 통해 수행하도록 구성해야 합니다.

Geo를 설정하는 일환으로, 기본 및 보조 노드 모두에 대해 아래에 나열된 단계를 따라야 하지만 “authorized keys” 파일에 쓰기는 기본 노드에서만 선택 취소해야 하며, 데이터베이스 복제가 작동하는 경우에만 이것은 자동으로 보조 노드에 반영됩니다.

빠른 조회 설정

GitLab 셸은 SSH 서버에서 빠르고 색인된 조회를 통해 SSH 사용자에게 인가하는 방법을 제공합니다. GitLab 셸은 SSH 키의 지문을 사용하여 사용자가 GitLab에 액세스할 수 있는지 확인합니다.

빠른 조회는 다음과 같은 SSH 서버에서 활성화할 수 있습니다:

두 서비스를 별도의 포트를 사용하여 동시에 실행할 수 있습니다.

gitlab-sshd 사용 시

gitlab-sshd를 설정하려면 gitlab-sshd 설명서를 참조하세요. gitlab-sshd를 활성화한 후에 GitLab 셸과 gitlab-sshd는 자동으로 빠른 조회를 사용하도록 구성됩니다.

OpenSSH 사용 시

caution
AuthorizedKeysCommand가 지문을 수락할 수 있어야 하기 때문에 OpenSSH 버전 6.9+가 필요합니다. 서버의 OpenSSH 버전은 sshd -V로 확인할 수 있습니다.

다음을 sshd_config 파일에 추가하세요. 이 파일은 보통 /etc/ssh/sshd_config에 위치하지만 리눅스 패키지 설치를 사용하면 /assets/sshd_config에 있습니다: 

Match User git    # AuthorizedKeysCommands를 오직 git 사용자에게만 적용
  AuthorizedKeysCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-keys-check git %u %k
  AuthorizedKeysCommandUser git
Match all    # 일치 종료, 설정이 다시 모든 사용자에게 적용

OpenSSH를 재로드하세요: 

# Debian 또는 Ubuntu 설치
sudo service ssh reload

# CentOS 설치
sudo service sshd reload

사용자의 키를 authorized_keys 파일에서 주석 처리하여 SSH가 작동하는지 확인하세요 (#으로 줄의 시작을 주석 처리하여 키를 주석 처리). 그리고 로컬 머신에서 리파지토리를 풀거나 다음을 실행해보세요: 

ssh -T git@gitlab.example.com

성공적인 풀이나 환영 메시지는 GitLab이 파일에 존재하지 않기 때문에 데이터베이스에서 키를 찾을 수 있었음을 의미합니다.

note
자체 컴파일 설치를 하는 경우, 명령은 소스에서 설치 지침에 따라 /home/git/gitlab-shell/bin/gitlab-shell-authorized-keys-check에 위치할 것입니다. 필요에 따라 이 명령을 다른 곳에 래퍼 스크립트를 만들 수 있지만, 이 명령은 root에서 소유되어 있어서 그룹 및 기타 사용자에게 쓰기가 허용되어서는 안됩니다. 필요한 경우 이 명령의 소유권을 변경하도록 고려할 수 있지만 이는 gitlab-shell 업그레이드 중에 임시 소유권 변경이 필요할 수 있습니다.
caution
SSH가 완벽하게 작동함이 확인되기 전에 “authorized_keys” 파일에 대해 쓰기를 비활성화하지 마세요. 그렇지 않으면 파일이 빠르게 오래되어 없어질 수 있습니다.

조회 실패의 경우(이는 일반적입니다), authorized_keys 파일은 여전히 스캔됩니다. 그러므로 큰 파일이 존재하는 한 많은 사용자에 대해 SSH 성능이 여전히 느릴 것입니다.

authorized_keys 파일에 대한 쓰기를 비활성화하려면:

  1. 왼쪽 사이드 바에서 맨 아래에서 관리자 영역을 선택합니다.
  2. 설정 > 네트워크를 선택합니다.
  3. 성능 최적화를 확장합니다.
  4. SSH 키를 인증하기 위해 authorized_keys 파일 사용 확인란을 체크해제합니다.
  5. 변경 사항 저장을 선택합니다.

다시 한 번 SSH가 작동하는지 확인하세요. UI에서 사용자의 SSH 키를 제거하고 새로 추가한 후 리파지토리를 풀어보세요.

그런 다음 성능을 위해 authorized_keys 파일을 백업하고 삭제할 수 있습니다. 현재 사용자의 키는 이미 데이터베이스에 있기 때문에 이동이나 사용자가 키를 다시 추가할 필요가 없습니다.

authorized_keys 파일을 다시 사용하는 방법

이 개요는 간략한 것입니다. 더 많은 맥락을 보려면 위의 지침을 참조하세요.

  1. authorized_keys 파일 다시 빌드
  2. authorized_keys 파일에 대한 쓰기 활성화
    1. 왼쪽 사이드 바에서 맨 아래에서 관리자 영역을 선택합니다.
    2. 왼쪽 사이드 바에서 설정 > 네트워크를 선택합니다.
    3. 성능 최적화를 확장합니다.
    4. SSH 키를 인증하기 위해 authorized_keys 파일 사용 확인란을 선택합니다.
  3. /etc/ssh/sshd_config 또는 Linux 패키지 설치를 사용하는 경우 /assets/sshd_config에서 AuthorizedKeysCommand 줄을 제거합니다.
  4. sshd를 다시로드합니다: sudo service sshd reload.

SELinux 지원 및 제한

GitLab은 SELinux의 authorized_keys 데이터베이스 조회를 지원합니다.

SELinux 정책이 정적이기 때문에 현재 GitLab은 내부 웹 서버 포트를 변경할 수 있는 기능을 지원하지 않습니다. 관리자는 환경을 위한 특별한 .te 파일을 생성해야 하며, 이는 동적으로 생성되지 않기 때문입니다.

추가 문서

gitlab-sshd에 대한 추가 기술 문서는 GitLab Shell 설명서에서 찾을 수 있습니다.

문제 해결

SSH 트래픽이 느리거나 높은 CPU 부하

만약 SSH 트래픽이 느리다면 또는 높은 CPU 부하를 일으킨다면, 반드시 /var/log/btmp의 크기를 확인하고 일정 기간이나 특정 크기에 도달하면 회전되도록 해야 합니다. 만약 이 파일이 아주 크다면, GitLab SSH 빠른 조회가 병목 현상이 더 자주 발생하게 할 수 있으므로 성능이 더 나빠질 수 있습니다. 가능하다면, sshd_config에서 UsePAM 비활성화를 고려하여 /var/log/btmp을 읽지 않도록 할 수 있습니다.

실행중인 sshd: git 프로세스에 대한 strace 및 lsof가 디버깅 정보를 반환합니다. IP가 x.x.x.x인 진행 중인 Git을 통한 SSH 연결에 대한 strace를 얻으려면 다음을 실행하세요: 

sudo strace -s 10000 -p $(sudo netstat -tp | grep x.x.x.x | egrep 'ssh.*: git' | sed -e 's/.*ESTABLISHED *//' -e 's#/.*##')

또는 실행 중인 Git을 통한 SSH 프로세스에 대한 lsof가져오기: 

sudo lsof -p $(sudo netstat -tp | egrep 'ssh.*: git' | head -1 | sed -e 's/.*ESTABLISHED *//' -e 's#/.*##')