SSH 키
설정 → 보안 → SSH 키.
이것이 토큰 옆에 있는 이유
Gitcito는 서로 다른 두 가지를 인증하는데, 사람들은 당연하다는 듯 그 둘을 하나로 여겨요:
| 무엇으로 인증하나 | |
|---|---|
| 호스트 API — 저장소, PR, 이슈, CI 검사 | 당신의 토큰 |
https:// 를 통한 git 전송 |
URL에 끼워 넣은 당신의 토큰 |
git@… 를 통한 git 전송 |
시스템 ssh를 거치는 당신의 SSH 키 |
git@github.com:me/api.git 같은 원격은 토큰을 건드리지도 않아요. git이 연결을
ssh 에 넘기는데, ssh 는 개인 접근 토큰이라는 것을 들어 본 적이 없죠. 이건
예외적인 상황이 아니에요 — 동료가 저장소를 설정했을 때, .gitmodules 가 git@
URL을 쓸 때, 회사가 HTTPS 인증을 막아 뒀을 때, 호스트가 직접 운영하는 GitLab일
때 늘 마주치게 되는 일이에요.
그게 어긋나면 ssh는 Permission denied (publickey) 라고만 말하고 끝이에요.
기술적으로는 맞는 말이지만, 조언으로는 쓸모가 없죠.
이 섹션이 알려주는 것
~/.ssh 에서 찾은 키마다 타입, 크기, 지문, 주석을 보여주고, 갑작스러운 실패
대부분을 설명해 주는 사실 하나를 덧붙여요:
에이전트에 있음 / 에이전트에 없음. 에이전트가 들고 있지 않은 키는 아무것도 인증할 수 없고, 운영체제에 따로 일러두지 않았다면 에이전트는 재부팅과 함께 내용을 잊어버려요. "어제는 됐는데"의 정체는 대개 이거예요.
여기서 할 수 있는 일
| 동작 | 실제로 실행하는 것 |
|---|---|
| 공개 키 복사 | .pub 한 줄을 클립보드에 올려서, 어느 호스트에든 바로 붙여 넣을 수 있게 해요 |
| 에이전트에 추가 | ssh-add (macOS에서는 --apple-use-keychain 을 붙여, 재부팅해도 남도록) |
| GitHub에 업로드 | 이 프로필의 토큰으로 POST /user/keys |
| 키 생성 | ssh-keygen -t ed25519, 주석에는 당신의 git 이메일 |
| 연결 테스트 | ssh -T git@<host> 를 사람의 문장으로 옮겨서 |
연결 테스트 가 있는 이유는 ssh 자신의 대답이 오해를 부르기 때문이에요. GitHub는 인증에 성공한 뒤에 실패 코드로 종료해요. 셸을 제공하지 않으니까요. Gitcito는 종료 코드가 아니라 메시지를 읽고, 그 아래에 원본 출력을 그대로 보여줘서 그 해석이 맞는지 직접 확인할 수 있게 해요.
한계, 있는 그대로
- 업로드는 GitHub 전용이에요. GitLab, Bitbucket, Azure DevOps에는 공개 키 복사 와 각자의 키 설정 페이지로 곧장 가는 링크가 있어요. 나머지 셋에 키를 등록하는 기능은 구현되어 있지 않고, 버튼도 그런 척하지 않아요.
- 생성은 절대 덮어쓰지 않아요.
~/.ssh에 이미 있는 이름은 거부해요. 개인 키를 조용히 덮어쓰면 그 키를 신뢰하던 모든 곳에 대한 접근이 취소되는데, 어떤 확인 대화 상자로도 되돌릴 수 없는 일이니까요. - 암호구(passphrase)는 Gitcito가 저장하지 않아요. 키를 만들거나 에이전트에
추가할 때 한 번 입력하면,
ssh-keygen/ssh-add에 전달되고 버려져요. 재부팅 너머로 유지하는 건ssh-add를 통해 OS 키체인이 할 일이에요. ~/.ssh/config편집은 없어요. 호스트 별칭도, 저장소별 키 선택도 없어요. 그런 것들은 당신의 ssh 설정에 사는 것이고, Gitcito는 그 파일에 손대지 않아요.
기기 밖으로 절대 나가지 않는 것
Gitcito는 개인 키를 읽지도, 표시하지도, 전송하지도 않아요. 이 섹션이 나열하는 것은 공개 쪽 절반과 지문뿐이에요. 어딘가로 보내지는 유일한 것은 당신이 직접 업로드 를 누른 공개 키 하나이고, 그마저도 지문을 명시한 확인을 거친 뒤 당신 자신의 토큰으로 GitHub에 가요.
함께 보기: 보안과 비밀 · 호스팅과 풀 리퀘스트