- 변경하지 않은 노트북에서 GitHub의
git pull이 갑자기 실패했지만, 개인 키에 대응하는 .pub 파일을 생성하자 다시 인증됨
.pub 파일이 있으면 OpenSSH는 공개 키를 먼저 제시해 승인을 받은 뒤 서명하고, 없으면 서명된 인증 요청을 즉시 전송함- 두 흐름 모두 RFC 4252에 부합하고 일반적인
sshd도 허용하지만, 당시 GitHub SSH 프런트엔드는 직접 서명된 요청을 받아들이지 않는 것으로 보였음
- 12차례 통제 시험에서
.pub 파일이 없던 6회는 모두 거부됐고, 파일이 있던 6회는 모두 성공함
- 서버 배너 변화로 서버 측 소프트웨어 변경 가능성을 추정할 수 있지만, 정확한 원인은 확인되지 않아 대응 공개 키 파일을 함께 유지하는 것이 안전함
갑작스러운 인증 실패와 해결
- 기본 노트북에서
git pull이 Permission denied (publickey) 오류와 함께 중단됨
- 해당 키는 여전히 GitHub에 등록돼 있었음
- 다른 키를 쓰는 노트북에서는 같은 저장소를 정상적으로 가져올 수 있었음
- 키와 클라이언트 설정에서는 이상을 찾지 못함
openssl rsa -check는 RSA key ok를 반환함- 최신 서명 알고리듬인
rsa-sha2-512를 사용 중이었음
~/.ssh/config에 문제가 없었고 GitHub 상태 페이지도 정상이었음
- 재설치 후
~/.ssh/github_rsa에 대응하는 공개 키 파일이 사라진 상태였으며, 다음 명령으로 생성하자 인증에 성공함
ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub
- 통제 시험에서는
.pub 파일이 없던 6회가 모두 실패하고, 있던 6회는 모두 성공함
.pub 파일에 따라 달라지는 인증 흐름
- OpenSSH는
.pub 파일의 존재 여부에 따라 서로 다른 공개 키 인증 흐름을 사용함
- 파일이 있으면 공개 키를 먼저 제시하고 서버의 승인을 기다린 뒤 서명함
- 개인 키만 있으면 사전 확인을 건너뛰고 완전히 서명된 인증 요청을 바로 보냄
- 두 방식 모두 RFC 4252가 허용하며, 일반적인
sshd는 둘 다 받아들임
- 당시 GitHub에서는 직접 서명된 공개 키 요청이 거부됐지만, GitHub 측의 실제 변경 여부는 확인되지 않음
- 디버그 로그의 서버 배너는 과거의
babeld-<hash> 형식이 아니라 6a2c000 으로 나타남
- 새로운 서버 소프트웨어가 직접 서명된 요청을 거부했을 가능성은 추정에 머묾
- 같은 문제를 피하려면 개인 키에 대응하는
.pub 파일을 함께 유지해야 함