GitHub SSH 중단 예고: RSA 키를 바꾸기 전에 서명 알고리즘부터 확인하기

같은 키로도 연결 방식이 달라질 수 있음을 표현한 생성형 개념 이미지다. 실제 GitHub 화면은 아니다.

GitHub에 접속하던 CI가 갑자기 인증에 실패하면 SSH 키부터 지우기 쉽다. 하지만 RSA 키를 사용하는 것과 SHA-1로 서명하는 것은 다르다. 먼저 실행 환경의 SSH 구현, 적용 설정, 실제 협상 결과를 나눠 확인해야 한다.

GitHub는 2026년 9월 22일 보안 변경을 발표하면서 11월 4일을 첫 일시 중단 시험일로 예고했다. 이 글은 그 일정에 맞춘 점검 가이드다. 실제 중단 시간이나 특정 장애의 원인을 확인한 사고 보고서는 아니다.

어떤 변경인지 먼저 좁힌다

제거 대상은 SHA-1 기반 ssh-rsa 서명과 diffie-hellman-group-exchange-sha256 키 교환이다. 공식 일정에는 2026년 12월 9일 두 번째 시험과 2027년 1월 13일 제거도 명시돼 있다. 발표에 시험의 정확한 시각·시간대·지속시간은 없으므로 한국 시간으로 임의 변환하지 않는다.

기존 RSA 키는 클라이언트가 rsa-sha2-256 또는 rsa-sha2-512로 서명하면 계속 사용할 수 있다. 공개키 파일 첫 단어가 ssh-rsa라는 이유만으로 교체 대상이라고 판단하면 안 된다. 신규 RSA 키 등록에 적용되는 3072비트 이상 조건은 별도의 규칙이다.

HTTPS 원격 저장소는 이번 SSH 변경의 대상이 아니다. Enterprise Server는 버전별 적용 일정도 별도로 확인해야 한다. GitHub 공식 변경 공지

지원 목록과 실제 사용은 다르다

OpenSSH에서는 세 층을 구분하면 원인을 찾기 쉽다.

바이너리가 지원하는 알고리즘

호스트별 설정을 반영한 허용 목록

실제 연결에서 사용한 알고리즘

다음은 로컬에서 정보를 읽는 명령이다. 프로젝트 경로에서 원격 주소를 먼저 확인한다.

-Q는 지원 기능을 조회하고, -G는 Host·Match 규칙을 적용한 설정을 출력한다. 둘 다 실제 서버와 인증에 성공했다는 증거는 아니다. 설정에 Match exec가 있다면 설정 평가 과정에서 로컬 명령이 실행될 수 있으므로, 자동화 환경에서는 설정 내용도 검토한다. OpenSSH 명령 설명, 설정 평가 규칙

이 글의 검증 환경에서는 OpenSSH 10.0p2로 다음 두 명령을 실제 실행했다. 사용자 계정이나 GitHub 인증에는 접근하지 않았다.

첫 출력에는 세 서명 이름이 모두 있었다. 반면 설정을 제외한 두 번째 출력의 pubkeyacceptedalgorithms에는 SHA-2 서명은 있고 SHA-1 ssh-rsa는 없었다. 구현이 알고 있다는 사실과 기본적으로 허용한다는 사실이 다름을 보여주는 로컬 결과다. 다른 운영체제나 배포판의 결과까지 보장하지 않는다.

실제 인증은 실행 주체별로 확인한다

계정 소유자가 이미 등록한 키로 확인할 때는 다음과 같이 상세 로그를 볼 수 있다.

처음 만나는 호스트라는 경고가 나오면 공식 GitHub 지문과 대조한다. 검증을 끄는 옵션으로 경고를 없애지 않는다. 정상 인증 메시지에 원하는 사용자명이 표시되는지 확인한다. GitHub는 셸을 제공하지 않으므로 인증 성공 시에도 이 시험 명령의 종료 코드는 1일 수 있다. GitHub SSH 연결 시험 문서

로그는 다음 질문을 구분하는 데 사용한다.

어떤 키를 제시했고 서버가 받아들였는가?

사용자 인증 서명에 어떤 알고리즘을 사용했는가?

키 교환은 무엇으로 협상됐는가?

인증이 실패한 것인가, 그 전에 DNS·TCP 연결이 실패한 것인가?

서버 호스트 키와 사용자 인증 키도 별개다. 로그에 RSA나 SHA라는 문자열이 있다는 사실 하나로 결론 내리지 않는다. 공유할 때는 사용자명·내부 주소·키 경로 등 환경 정보를 가린다.

노트북보다 배포 실행기를 먼저 점검한다

다음은 공식 변경사항을 바탕으로 제안하는 운영 절차다. 실제 장애 분석 결과는 아니다.

개발자의 최신 터미널이 통과해도 오래된 컨테이너, Java 빌드 도구, Go 기반 배포 프로그램은 다른 SSH 구현을 사용할 수 있다. 따라서 점검표의 단위는 사람이나 저장소가 아니라 실제로 Git을 실행하는 환경으로 잡는다.

개발 PC, CI 이미지, 배포 서버, 내장 Git 도구를 구분한다.

각 환경에서 SSH 실행 파일 또는 라이브러리 버전과 설정을 기록한다.

전환한 이미지로 테스트 저장소의 읽기 작업부터 검증한다.

정상 인증과 실제 저장소 접근 권한을 따로 확인한다.

수정 완료 후 다음 중단 시험과 영구 제거 전에 다시 점검한다.

같은 날 발생한 모든 Permission denied를 이번 변경으로 묶지 않는다. 키 등록, 계정 선택, 저장소 권한, 에이전트 상태, 서비스 장애도 후보로 남겨 둔다. 실패 메시지와 협상 로그가 있어야 원인을 좁힐 수 있다.

키 교체보다 먼저 할 일

기존 RSA 키를 무조건 재발급하는 대신 SHA-2를 지원하는 클라이언트와 설정으로 전환하는 것이 먼저다. 서버가 제거한 방식을 클라이언트에서 강제로 허용해도 장기적인 해결책이 되지 않는다.

키 교체가 필요하다고 판단한 경우에도 다른 서비스가 그 키를 사용하는지 확인하고, 새 연결을 검증한 뒤 기존 키를 정리한다. 이 글에서는 키 생성·등록·삭제, 계정 설정 변경, 실제 GitHub 로그인 시험을 실행하지 않았다. 확인한 것은 공개 일정과 로컬 SSH 조회 결과다.