GitHub이 갑자기 SSH 키를 거부한 이유: 사라진 .pub 파일

• 변경하지 않은 노트북에서 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에 대응하는 공개 키 파일이 사라진 상태였으며, 다음 명령으로 생성하자 인증에 성공함

• 통제 시험에서는 .pub 파일이 없던 6회가 모두 실패하고, 있던 6회는 모두 성공함

.pub 파일에 따라 달라지는 인증 흐름

• OpenSSH는 .pub 파일의 존재 여부에 따라 서로 다른 공개 키 인증 흐름을 사용함
  • 파일이 있으면 공개 키를 먼저 제시하고 서버의 승인을 기다린 뒤 서명함
  • 개인 키만 있으면 사전 확인을 건너뛰고 완전히 서명된 인증 요청을 바로 보냄
• 두 방식 모두 RFC 4252가 허용하며, 일반적인 sshd는 둘 다 받아들임
• 당시 GitHub에서는 직접 서명된 공개 키 요청이 거부됐지만, GitHub 측의 실제 변경 여부는 확인되지 않음
  • 디버그 로그의 서버 배너는 과거의 babeld-<hash> 형식이 아니라 6a2c000 으로 나타남
  • 새로운 서버 소프트웨어가 직접 서명된 요청을 거부했을 가능성은 추정에 머묾
• 같은 문제를 피하려면 개인 키에 대응하는 .pub 파일을 함께 유지해야 함