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

> Clean Markdown view of GeekNews topic #31676. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31676](https://news.hada.io/topic?id=31676)
- GeekNews Markdown: [https://news.hada.io/topic/31676.md](https://news.hada.io/topic/31676.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-22T09:06:53+09:00
- Updated: 2026-07-22T09:06:53+09:00
- Original source: [thorsell.io](https://thorsell.io/2026/07/21/github-ssh-keys.html)
- Points: 1
- Comments: 1

## Topic Body

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

```shell
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` 파일을 함께 유지**해야 함

## Comments



### Comment 62194

- Author: neo
- Created: 2026-07-22T09:06:54+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/twqtlo/github_suddenly_rejected_my_ssh_key_fix) 
- 지난 **4시간 동안 같은 문제**를 겪고 있으며, 이미 https://www.githubstatus.com/incidents/g40zcbvchny4 에 등록돼 있음

- 몇 주 전 SSH 키를 교체하면서 Git에서 무시되던 기존 **`.pub` 파일**을 삭제하지 않았는데, 새 키로 접속해도 계속 실패했음  
  디버그 옵션을 여러 개 켠 뒤에야 SSH 클라이언트가 예전 지문을 보내고 있다는 사실을 알아냈으며, OpenSSH가 `.pub` 파일을 읽는다는 것 자체를 몰랐고 그동안 완전히 불필요한 파일이라고 여겨왔음

- 오늘 CI 서버가 갑자기 github.com에 접속하지 못하는 듯한 **동일한 장애**를 겪었음  
  키를 올바른 **ed25519 키**로 교체하자 다시 작동했지만, 이 키에도 짝이 되는 `.pub` 파일이 없어 왜 해결됐는지는 알 수 없음
  - 키가 갑자기 작동하지 않아 침해 사고부터 걱정했는데, 이제 GitHub가 직접 대응 중인 듯해 다행임

- 오늘 같은 문제를 겪었으며, GitHub가 **SSH 인증 동작 변경**을 계획했다는 공지는 아는 한 없었음
  - 계획된 변경이었을 것 같지는 않음

- 비밀번호와 복구 키를 모두 잃어버려 **SSH 키 기반 계정 복구** 절차를 거쳤지만, GitHub가 해당 SSH 키를 만료 처리하는 바람에 계정 접근 권한을 완전히 잃었음

- 7~8년 동안 `.pub` 파일을 둔 적이 없는 것 같아, 다음에 GitHub를 사용하기 전에는 문제가 해결되길 바람
  - 공개 키 파일은 간단히 다시 생성할 수 있으며, 해당 명령어도 **원문 글**에 나와 있음

- 두 인증 흐름이 모두 적법하다면 왜 **키 탐색 흐름**이 존재하는지 의문임  
  이런 이상 동작만 유발하는 것 같고, 어차피 개인 키에서 공개 키를 만들 수 있다면 SSH가 자동으로 처리하면 될 듯함
  - 개인 키가 암호화됐거나 **하드웨어 보안 토큰**에 저장돼 즉시 사용할 수 없는 상황을 위한 기능임  
    SSH는 서버에 어떤 키가 통할지 먼저 확인해, 인증에 확실히 실패할 키를 사용자가 불필요하게 복호화하지 않도록 함  
    이 동작에는 https://github.com/FiloSottile/whoami.filippo.io 같은 특이한 부작용도 있으므로, 사용자가 실수로 잘못된 서버에 접속했을 때를 대비해 서버가 클라이언트의 공개 키를 미리 알아야만 인증을 시도할 수 있는 방식도 허용할 필요가 있음

- 업무용 **Office 365 계정**도 5년 만에 처음으로 오늘 갑자기 작동을 멈췄음  
  Microsoft에서 침해 사고가 발생해 모든 값을 다시 솔팅했거나, 최근 Chat Control 1.0 표결 때문에 유럽 사용자에게만 생긴 일인지 궁금함
  - GitHub의 **연결 종료 서비스**와 M365 계정 인증은 전혀 관련이 없으며, 우연의 일치라고 99.999% 확신함  
    GitHub의 Git Systems와 Microsoft의 Office/M365 제품군 양쪽에서 일해본 것으로 아는 두 사람 중 한 명이라 이렇게 단언할 자격도 충분함  
    설령 두 서비스에 동일하게 적용되는 정책이나 기술 변경이 원인이더라도, 서로 단절된 시스템이라 같은 날 배포될 가능성은 극히 낮음