• 변경하지 않은 노트북에서 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

파일을 함께 유지해야 함