Git · 협업 · 약 3분
GitHub SSH 연결: 공개 키와 개인 키를 안전하게 구분하기
커밋 작성자 정보와 서버 인증을 분리하고, 기존 키를 덮어쓰지 않는 SSH 설정·확인 순서를 정리합니다.
Wolfgadeok · 업데이트
이메일 설정은 로그인 설정이 아니다
git config의 user.name과 user.email은 커밋에 기록되는 작성자 정보입니다. 해당 이메일을 입력했다고 GitHub에 로그인되는 것은 아닙니다. SSH 접속 권한은 서버에 등록된 공개 키와 로컬에서 보유한 개인 키 등 인증 설정으로 결정됩니다. ssh-keygen의 -C로 넣는 문자열도 키를 구분하는 주석이지 서버가 이메일의 일치를 검사하는 인증 암호가 아닙니다.
SSH는 암호화된 연결 위에서 인증과 데이터 전송을 제공하는 프로토콜입니다. GitHub에 SSH로 연결한다고 일반 원격 셸을 제공받는 것은 아닙니다. Git 작업에 필요한 접속이 허용되는 것입니다. HTTPS도 다른 정상적인 선택이며, 어느 한 방식이 항상 더 빠르거나 무조건 더 안전하다고 단정하기보다 조직 정책과 자격 증명 관리 방식에 맞춥니다.
키를 만들기 전에 기존 설정부터 확인하기
개인 키는 외부에 보내거나 저장소에 올리지 않습니다. .pub로 끝나는 공개 키만 GitHub의 SSH 키 등록 화면에 추가합니다. 개인 키는 사용자 PC에 남겨 두고, 필요하면 암호문구와 ssh-agent를 사용합니다. 이미 사용하는 키가 있는데 기본 파일명으로 다시 생성하면 다른 프로젝트의 접속까지 깨질 수 있으므로 덮어쓰기 질문에 무심코 동의하지 마세요.
아래 예제는 Git Bash용이며, PowerShell의 Windows OpenSSH 서비스 설정과 섞어 실행하지 않습니다. 먼저 기존 키와 정책을 확인하고 새 키가 필요한 경우에만 첫 명령을 사용합니다. 저장 위치 질문에는 기존 키와 겹치지 않는 파일명을 지정하고, 암호문구를 설정합니다. 다음 두 명령의 파일 경로는 실제로 생성한 개인 키 경로로 맞춰야 합니다.
예제 · bash
# 기존 키를 확인한 뒤, 새 키가 필요할 때만 실행합니다.
ssh-keygen -t ed25519 -C "development-machine"
# Git Bash에서 사용하는 예시입니다.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
# 공개 키 등록 후 접속을 확인합니다.
ssh -T git@github.com처음 접속할 때와 문제가 생겼을 때
처음 접속할 때 호스트 키 지문을 신뢰할지 물으면 GitHub 공식 지문 문서와 대조합니다. 무조건 yes를 입력하거나 호스트 키 검사를 끄는 방식으로 문제를 숨기지 않습니다. 호스트 키는 내가 접속한 서버가 맞는지를 확인하는 정보이며, 내 계정을 인증하는 개인 키와 역할이 다릅니다.
인증이 성공했는데 저장소 접근이 실패하면 대상 주소와 저장소 권한을 따로 확인합니다. Windows에서는 Git에 포함된 SSH와 Windows OpenSSH가 공존하여 서로 다른 agent를 사용할 수 있습니다. 이때도 새 키를 계속 만드는 대신 어떤 ssh 실행 파일과 agent를 쓰는지부터 확인합니다. 키가 유출됐다면 공개 키 등록을 폐기하고 새 키로 교체해야 하며, 파일만 지웠다고 원격 권한이 철회되지는 않습니다.
참고 자료
예제는 학습용이며, 모든 환경에서 실행 검증된 완성 프로젝트는 아닙니다. 적용 전 사용 중인 버전과 프로젝트 환경에서 동작을 확인하세요.