Permission denied (publickey)는 저장소 권한이 없어서가 아니라 이번 SSH 시도에 깃허브가 받은 공개키가 계정에 없어 거절한 줄입니다. 접속 시험, 에이전트, 키 전용 옵션, 배포 키를 순서대로 봅니다. GitHub, 맥, 한국 1인 넥스트 기준. 2026년 9월 깃허브 SSH 공식 문서.
Permission denied (publickey)는 저장소 권한이 없어서가 아니라, 이번 SSH 시도에 깃허브가 받은 공개키가 계정에 없어서 거절한 줄입니다. 그래서 토큰을 다시 넣기 전에 어떤 키가 나갔는지부터 보세요.
git push가 막히고, 같은 맥에서 브라우저는 되는 일, 한국에서 회사 저장소와 개인 저장소를 한 노트북으로 다루는 1인이면 한 번은 만납니다. 파일 권한 EACCES와는 칸이 다릅니다.
ssh-add -l과 깃허브 SSH 키 목록을 나란히 보기 전에는 키를 새로 만들지 마세요. 근거는 깃허브 publickey 문서와 SSH 연결 안내에 있습니다.
SSH가 보낸 키가 깃허브 계정·배포 키 목록에 없을 때 납니다. 저장소 협업자 권한이 없어도 나중 단계에서 거절되지만, 메시지에 publickey가 있으면 그 전 단계입니다. 인증 자체가 실패한 겁니다. 키 파일이 디스크에 있어도 에이전트에 안 올라갔거나, 올라간 손이 다른 계정이면 같은 줄이 납니다.
HTTPS 원격은 이 줄이 안 납니다. remote가 git@github.com 이면 SSH입니다. 브라우저는 HTTPS로 로그인돼 있어 푸시만 막히는 그림이 나옵니다. 카카오 로그인 앱 저장소를 혼자 운영하다 원격 URL만 SSH로 바꿨을 때 자주 만납니다.
파일 시스템 권한 줄은 EACCES입니다. 깃 잠금 파일은 index.lock입니다. 커밋 이메일이 회사와 개인으로 갈리는 문제는 includeIf 글입니다. 여기는 키가 계정에 있느냐만 봅니다.
먼저 볼 것 | ssh -T git@github.com이 실패하면 깃 설정보다 키가 먼저입니다. Hi username 이 나오면 키는 통과고, 그다음 저장소 권한을 보면 됩니다.
에이전트에 올라간 키와 깃허브에 등록된 지문을 대조합니다.
| 칸 | 증상 | 먼저 할 일 |
|---|---|---|
| 에이전트 비어 있음 | 재부팅 뒤만 실패 | ssh-add -l, 맥 키체인 |
| 다른 키 우선 | 회사 키로 개인 저장소 시도 | IdentitiesOnly, 호스트 별칭 |
| 깃허브에 미등록 | 로컬에 키는 있음 | .pub 내용을 SSH keys에 붙여넣기 |
| 배포 키 오용 | 한 저장소만 되고 다른 건 실패 | 배포 키는 그 저장소 전용 |
| HTTPS 원격 | 이 메시지가 안 나야 정상 | git remote -v 가 ssh인지 |
맥은 재부팅 후 에이전트가 비는 경우가 많습니다. 키 파일은 디스크에 있는데 ssh-add가 안 되어 있으면 깃허브는 빈 손을 받습니다. 회사 키와 개인 키가 둘 다 에이전트에 있으면, SSH는 앞쪽 키부터 시도하다 거절을 받고 다음을 안 고를 수 있습니다.
나간 키와 깃허브 계정 확인ssh-add -l ssh -vT git@github.com # debug1: Offering public key 줄을 본다 # Hi USERNAME! 가 나오면 키는 통과 git remote -v # git@github.com:org/repo.git 이면 SSH # https://github.com/org/repo.git 이면 이 에러 칸이 아니다
개인과 회사 키를 한 노트북에 두면 호스트 별칭이 필요합니다. ~/.ssh/config에 github.com-work 같은 이름을 만들고, 원격 URL도 그 호스트를 쓰게 바꿉니다. IdentitiesOnly yes를 넣어야 다른 키가 먼저 나가지 않습니다.
깃허브 문서는 새 키를 만들고 ssh-agent에 올린 뒤, 공개키를 계정 SSH keys에 붙이라고 적습니다. 키가 이미 있는데 거절이면 새로 만들기보다 등록과 별칭이 먼저입니다. 배포 키는 쓰기 권한이 없거나 한 저장소만 열려 있어, 개인 계정 키와 섞으면 헷갈립니다.
워크트리로 핫픽스를 나누는 흐름은 워크트리 글입니다. 키 문제는 워크트리마다 다르지 않고, 그 머신 SSH 설정 한 벌입니다. 포트 권한이 아니라서 sudo를 붙일 자리가 아닙니다.
~/.ssh/config 호스트 별칭 예시Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519 IdentitiesOnly yes Host github.com-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work IdentitiesOnly yes # 회사 원격 예 # git remote set-url origin git@github.com-work:company/repo.git
로컬만 막히면 키입니다. 깃허브 액션만 막히면 그 잡에 배포 키나 앱 토큰이 없습니다. 액션은 노트북 에이전트를 쓰지 않습니다. secrets에 넣은 키와 checkout persist-credentials를 보세요.
HTTPS로 바꾸면 이 메시지는 사라집니다. 대신 자격 증명이 다른 칸으로 갑니다. 1인 넥스트 저장소는 SSH가 편하고, 회사 SSO가 있는 조직은 HTTPS + 토큰이 더 단순한 경우도 있습니다. 메시지에 publickey가 있는 한, 토큰 재발급보다 SSH 테스트를 먼저 하세요.
호스트 키 검증 실패는 다른 문장입니다. REMOTE HOST IDENTIFICATION HAS CHANGED 는 known_hosts 칸이고, publickey 거절이 아닙니다. DNS가 github.com을 못 푸는 줄은 ENOTFOUND입니다.
| 메시지 | 단계 | 다음 |
|---|---|---|
| Permission denied (publickey) | 인증, 키 목록 | 이 글 |
| Repository not found | 인증 후 권한·이름 | 저장소 접근, 오타 |
| index.lock | 로컬 잠금 | 잠금 글 |
| EACCES | 파일·포트 권한 | EACCES 글 |
키를 채팅에 붙이지 말 것 | 개인키는 절대 이슈·슬랙·카카오톡에 붙이지 않습니다. 공개키(.pub)만 깃허브에 등록합니다. 유출되면 그 키를 계정에서 지우고 새로 만듭니다.
원격 URL이 SSH인지 확인하고, ssh -T로 계정 이름을 봅니다. 실패하면 ssh -vT로 Offering public key 줄을 읽습니다. 에이전트가 비었으면 ssh-add, 키가 안 나가면 config, 나가는데 거절이면 깃허브 목록에 .pub을 붙입니다.
Hi 이름이 다른 계정이면 키가 다른 손에 묶인 겁니다. 회사 계정 키로 개인 저장소를 밀고 있는 경우가 많습니다. 별칭으로 원격을 나눕니다. 그래도 안 되면 저장소 권한 단계로 넘어갑니다.
새 키는 마지막입니다. 한 쌍을 만들고 에이전트에 올리고 공개키 파일만 등록합니다. 맥 열쇠고리 연동을 설정 파일에 두면 재부팅 뒤에도 버팁니다. 포트 종료나 패키지 설치 권한과는 자리가 다릅니다. 회사 노트북을 개인 저장소와 같이 쓰는 한국 1인이면, 계정 이름을 확인하는 한 줄이 키를 새로 만드는 시간보다 짧습니다.
내부 연계: EACCES 권한, index.lock, 커밋 이메일 계정, 워크트리, DNS
인용한 동작은 2026년 9월 공개 문서 기준입니다.
웹은 HTTPS 세션이고 push는 SSH일 때가 많습니다. ssh -T가 실패하면 저장소 권한이 아니라 키입니다. Hi 이름이 나온 뒤에야 Collaborator를 보면 됩니다.
에이전트가 비었습니다. ssh-add -l이 비어 있으면 키 파일을 다시 올립니다. 맥이면 UseKeychain을 config에 두면 다음 재부팅부터 덜 반복됩니다.
디스크에 키가 있는데 거절이면 등록과 별칭이 먼저입니다. 새로 만들면 깃허브 목록이 늘어 다음에 더 헷갈립니다. verbose로 나간 손을 본 뒤에 만드세요.
개인 키가 먼저 나가 회사 조직이 거절한 그림입니다. 호스트 별칭과 IdentitiesOnly로 회사 키만 나가게 하세요. SSO 조직은 계정에서 SSH 키를 authorize 해야 할 수도 있습니다.
안 됩니다. root의 키는 다른 집입니다. 파일 권한 줄이 아니라 SSH 인증 줄이라 sudo는 칸이 다릅니다. EACCES 글의 처방을 여기 가져오지 마세요.
노트북 키는 잡에 없습니다. deploy key나 GitHub App 토큰을 그 워크플로에 넣어야 합니다. 로컬 ssh-add가 초록이어도 액션은 별개입니다.
publickey 거절은 이번에 나간 키가 깃허브 목록에 없다는 뜻입니다. ssh -T로 이름을 확인하고, 에이전트와 .pub 등록과 별칭을 맞추세요. 관련 글: EACCES, 커밋 이메일, index.lock.
