SSH 및 토큰을 사용한 일반적인 Git 인증 오류 해결
원격 URL을 SSH 키, HTTPS 토큰 및 자격 증명 도우미와 일치시켜 일반적인 Git 인증 실패를 수정합니다.
SSH 및 토큰을 사용한 일반적인 Git 인증 오류 해결
대부분의 Git 인증 문제는 원격 URL, Git이 사용하려는 자격 증명 및 Git 호스팅 계정의 권한 간의 불일치로 인해 발생합니다. 오류 텍스트는 극적으로 보일 수 있지만, Git이 어떤 경로를 사용하고 있는지 알면 일반적으로 기계적으로 수정할 수 있습니다.
원격 URL부터 시작하세요:
git remote -v
https://github.com/org/repo.git이 표시되면 Git은 HTTPS를 사용 중이며 사용자 이름과 토큰 또는 이를 제공할 수 있는 자격 증명 도우미가 필요합니다. [email protected]:org/repo.git이 표시되면 Git은 SSH를 사용 중이며 호스트에 등록된 공개 키와 일치하는 개인 키가 필요합니다.
문제 해결 중에는 두 가지를 혼합하지 마십시오. HTTPS 또는 SSH를 선택하고 원격 URL을 일치시킨 다음 해당 경로를 직접 테스트하십시오.
오류를 문자 그대로 읽으십시오
fatal: Authentication failed for 'https://...'는 일반적으로 Git이 서버에 도달했지만 유효한 HTTPS 자격 증명을 제시하지 않았음을 의미합니다. 이전 자격 증명이 캐시되었거나, 토큰이 만료되었거나, 토큰이 해당 리포지토리에 대한 액세스 권한이 없을 수 있습니다.
remote: Permission to org/repo denied 또는 403 Forbidden은 일반적으로 신원이 인식되었지만 작업에 대한 권한이 없음을 의미합니다. 예를 들어, 잘못된 계정의 토큰, 쓰기 액세스 권한이 없는 토큰 또는 다른 사용자에게 연결된 SSH 키를 사용하고 있을 수 있습니다.
Permission denied (publickey)는 SSH가 서버가 수락하는 키를 제공하지 않았음을 의미합니다.
HTTPS를 통한 반복적인 사용자 이름/비밀번호 프롬프트는 일반적으로 Git이 계속 거부를 받고 다시 묻는 것을 의미합니다. Git 작업에 토큰이 필요한 호스트에서는 계정 비밀번호를 반복해서 입력해도 도움이 되지 않습니다.
개인 액세스 토큰으로 HTTPS 수정
HTTPS 원격의 경우 Git 호스트 계정 설정에서 개인 액세스 토큰을 만드십시오. GitHub, GitLab, Bitbucket 및 자체 호스팅 플랫폼 간에 정확한 메뉴 이름은 다르지만 형태는 동일합니다. 토큰을 만들고, 리포지토리 액세스 권한을 부여하고, 조직 정책에 맞는 만료일을 설정하고, 즉시 복사하십시오.
Git이 메시지를 표시하면 일반 사용자 이름을 사용하고 토큰을 비밀번호로 붙여넣으십시오:
Username: your-username
Password: <paste-token-here>
가장 좁은 권한을 사용하십시오. 푸시하는 개인 리포지토리의 경우 읽기 및 쓰기 리포지토리 액세스 권한이 필요합니다. 공개 리포지토리를 복제하는 경우 토큰이 전혀 필요하지 않을 수 있습니다. 세분화된 토큰 및 조직 SSO 규칙은 또 다른 계층을 추가할 수 있습니다. 토큰이 존재하더라도 회사 리포지토리에 액세스하려면 승인 또는 SSO 인증이 필요할 수 있습니다.
Git이 새 토큰을 묻지 않으면 이전에 캐시된 자격 증명을 사용하고 있을 수 있습니다. 호스트에 대한 저장된 항목을 지운 다음 다시 시도하십시오.
macOS에서는 키체인 접근에서 github.com 또는 git:https://github.com과 같은 Git 호스트 관련 항목을 확인하십시오.
Windows에서는 자격 증명 관리자를 열고 호스트에 대한 관련 일반 자격 증명을 제거하십시오.
Linux에서는 구성된 도우미를 검사하십시오:
git config --global --get credential.helper
git config --show-origin --get-all credential.helper
cache 도우미는 자격 증명을 메모리에 임시로 저장합니다. store 도우미는 더 안전한 스토리지 계층을 구성하지 않는 한 자격 증명을 일반 텍스트로 디스크에 기록하므로 주의해서 사용하십시오. Git의 자격 증명 도우미 시스템은 도우미에게 자격 증명을 요청하고 도우미가 성공적인 자격 증명을 저장하도록 설계되었습니다. 보안은 선택한 도우미에 따라 다릅니다.
유용한 HTTPS 재설정 시퀀스는 다음과 같습니다:
git remote -v
git config --show-origin --get-all credential.helper
# OS 자격 증명 저장소에서 이전 자격 증명 제거
git ls-remote origin
git ls-remote origin은 작업 트리를 변경하지 않고 원격에 연결하므로 깔끔한 테스트입니다.
SSH 키로 수정
SSH 원격의 경우 먼저 키가 이미 있는지 확인하십시오:
ls -al ~/.ssh
일반적인 키 이름에는 id_ed25519, id_rsa 및 github_work_ed25519와 같은 호스트별 이름이 포함됩니다. .pub 파일은 Git 호스트에 업로드하는 공개 키입니다. .pub이 없는 파일은 개인 키이며 공유해서는 안 됩니다.
새 키가 필요한 경우 최신 시스템에서는 Ed25519가 좋은 기본값입니다:
ssh-keygen -t ed25519 -C "[email protected]"
자동화를 위한 특별한 이유가 없는 한 암호를 사용하십시오. 그런 다음 공개 키를 Git 호스트 계정 또는 배포 키 설정에 추가하십시오:
cat ~/.ssh/id_ed25519.pub
연결을 직접 테스트하십시오:
ssh -T [email protected]
GitLab 또는 Bitbucket의 경우 호스트 이름을 바꾸십시오. 성공적인 테스트는 일반적으로 인사말이나 셸 액세스가 제공되지 않는다는 메시지를 출력합니다. 괜찮습니다. Git-over-SSH 인증은 여전히 작동할 수 있습니다.
SSH가 여전히 실패하면 SSH 클라이언트가 무엇을 하고 있는지 물어보십시오:
ssh -vT [email protected]
어떤 키가 제공되는지 보여주는 줄을 찾으십시오. 키가 제공되지 않으면 에이전트에 로드하십시오:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
동일한 호스트에 여러 계정이 있는 경우 ~/.ssh/config를 사용하여 Git이 어떤 키가 어떤 원격에 속하는지 알 수 있도록 하십시오:
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/github_work_ed25519
IdentitiesOnly yes
그런 다음 리포지토리를 해당 별칭으로 지정하십시오:
git remote set-url origin git@github-work:org/repo.git
이렇게 하면 SSH가 개인 키를 작업 리포지토리에 제공하는 일반적인 문제를 피할 수 있습니다.
프로토콜을 깔끔하게 전환
팀이 SSH를 표준으로 사용하는 경우 HTTPS 원격을 다음과 같이 변경하십시오:
git remote set-url origin [email protected]:ORG/REPO.git
회사에서 SSH를 차단하거나 HTTPS 검사를 요구하는 경우 다른 방향으로 전환하십시오:
git remote set-url origin https://github.com/ORG/REPO.git
URL을 변경한 후 읽기 작업으로 테스트하십시오:
git fetch origin
그런 다음 실패한 작업을 테스트하십시오:
git push origin HEAD
가져오기는 작동하지만 푸시가 실패하면 인증은 유효하고 권한 부여가 문제일 가능성이 높습니다. 브랜치 보호, 리포지토리 역할, 토큰 범위 및 조직 SSO 규칙을 확인하십시오.
CI 및 서버 환경
빌드 에이전트 및 서버에서는 가능하면 사람의 개인 토큰을 사용하지 마십시오. 배포 키, 머신 사용자 또는 CI 시스템의 내장 자격 증명 저장소를 선호하십시오. 비밀을 명령 기록 및 로그에서 멀리 유지하십시오. 통제된 임시 환경이 아닌 경우 다음과 같이 토큰을 원격 URL에 붙여넣지 마십시오:
https://[email protected]/org/repo.git
해당 스타일은 로그, 프로세스 목록, 셸 기록 및 구성 파일을 통해 유출될 수 있습니다.
Jenkins, GitHub Actions 러너, GitLab 러너 및 유사한 시스템의 경우 플랫폼의 비밀 메커니즘에 자격 증명을 저장하고 필요한 작업에만 주입하십시오.
빠른 체크리스트
막혔을 때 순서대로 실행하십시오:
git remote -v
git ls-remote origin
URL이 HTTPS인 경우 이전에 캐시된 자격 증명을 지우고 올바른 리포지토리 권한이 있는 현재 토큰을 사용하십시오.
URL이 SSH인 경우 다음을 실행하십시오:
ssh -T git@your-hostname
ssh -vT git@your-hostname
예상 키가 제공되고 해당 공개 키가 올바른 계정에 등록되어 있는지 확인하십시오.
인증은 성공하지만 푸시가 실패하면 권한 부여 규칙을 찾으십시오: 보호된 브랜치, 누락된 쓰기 역할, 만료된 SSO 인증, 읽기 전용 배포 키 또는 쓰기 권한이 없는 토큰.
신뢰할 수 있는 수정 방법은 임의의 비밀번호를 시도하는 것이 아닙니다. 원격 프로토콜을 자격 증명 유형과 일치시키고, 오래된 캐시 자격 증명을 제거하고, 연결을 직접 테스트한 다음 리포지토리의 권한을 확인하십시오.