데이터베이스에서 권한 있는 SSH 키의 빠른 조회

Tier: Free, Premium, Ultimate
Offering: Self-managed
note
이 문서는 authorized_keys 파일에 대한 드롭인 교체 방법을 설명합니다. 표준(비 배포 키) 사용자에게는 SSH 인증서를 사용하는 것을 고려하세요. 이것은 더 빠르지만 드롭인 교체는 아닙니다.

사용자가 늘어남에 따라 OpenSSH가 사용자를 인증하기 위해 키를 검색하는 데 선형 검색을 사용하기 때문에 일반 SSH 작업은 느려집니다. 최악의 경우, 사용자가 GitLab 접근 권한이 없는 경우와 같이, OpenSSH는 키를 검색하기 위해 전체 파일을 스캔합니다. 이는 상당한 시간과 디스크 I/O를 소모할 수 있으며, 이는 사용자들이 리포지토리에 푸시하거나 풀하려고 할 때 지연이 발생합니다. 문제를 악화시키는 것은 사용자가 키를 자주 추가하거나 제거할 경우 운영 체제가 authorized_keys 파일을 캐시하지 못할 수 있고, 이로 인해 디스크에 반복적으로 접근하게 됩니다.

GitLab Shell은 GitLab 데이터베이스에서 빠르고 인덱스된 조회를 통해 SSH 사용자를 인증하는 방법을 제공합니다. 이 페이지에서는 권한 있는 SSH 키의 빠른 조회를 활성화하는 방법을 설명합니다.

빠른 조회는 Geo에 필요합니다

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

Cloud Native GitLab와 달리 기본적으로 리눅스 패키지 설치는 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 Shell은 GitLab 데이터베이스에서 빠르고 인덱스된 조회를 통해 SSH 사용자를 인증하는 방법을 제공합니다. GitLab Shell은 SSH 키의 지문을 사용하여 사용자가 GitLab에 접근할 수 있는 권한이 있는지 확인합니다.

다음 SSH 서버에서 빠른 조회를 활성화할 수 있습니다:

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

gitlab-sshd 사용 시

gitlab-sshd를 설정하려면 설정 방법을 참조하세요. gitlab-sshd가 활성화되면 GitLab Shell과 gitlab-sshd가 자동으로 빠른 조회를 사용할 수 있도록 구성됩니다.

OpenSSH 사용 시

caution
OpenSSH 버전 6.9+가 필요합니다. AuthorizedKeysCommand는 지문을 수용할 수 있어야 합니다. 서버에서 OpenSSH 버전을 확인하려면 sshd -V를 사용하세요.

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

Match User git    # git 사용자에게만 AuthorizedKeysCommands 적용  
  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 파일은 여전히 스캔됩니다. 때문에 많은 사용자는 큰 파일이 존재하는 한 여전히 Git SSH 성능이 느려질 것입니다.

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

  1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.
  2. Settings > Network를 선택합니다.
  3. Performance optimization을 확장합니다.
  4. Use authorized_keys file to authenticate SSH keys 체크박스를 지웁니다.
  5. Save changes를 선택합니다.

UI에서 사용자의 SSH 키를 제거하고 새로운 키를 추가한 후 리포지토리를 풀어 SSH가 작동하는지 확인합니다.

그런 다음 최상의 성능을 위해 authorized_keys 파일을 백업하고 삭제할 수 있습니다. 현재 사용자들의 키는 이미 데이터베이스에 존재하므로 마이그레이션이 필요하지 않으며 사용자가 키를 다시 추가할 필요도 없습니다.

authorized_keys 파일로 돌아가는 방법

이 개요는 간단합니다. 더 많은 맥락을 위해 위의 지침을 참조하십시오.

  1. authorized_keys 파일 재구성하기.
  2. authorized_keys 파일에 대한 쓰기 권한을 활성화합니다.
    1. 왼쪽 사이드바 하단에서 관리를 선택합니다.
    2. 왼쪽 사이드바에서 설정 > 네트워크를 선택합니다.
    3. 성능 최적화를 확장합니다.
    4. SSH 키 인증에 authorized_keys 파일 사용 체크박스를 선택합니다.
  3. /etc/ssh/sshd_config 또는 Docker에서 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 빠른 조회가 병목 현상을 더 자주 발생시켜 성능이 더욱 저하될 수 있습니다.

가능하다면, /var/log/btmp를 전혀 읽지 않도록 sshd_config에서 UsePAM 비활성화를 고려할 수 있습니다.

실행 중인 sshd: git 프로세스에서 stracelsof를 실행하여 디버깅 정보를 반환할 수 있습니다.

IP x.x.x.x에 대한 진행 중인 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 over SSH 프로세스에 대한 lsof를 얻으십시오:

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