GitHub CLI apt update EXPKEYSIG·NO_PUBKEY 오류 해결법

 

💻 목요일 밤, 서버나 개발 PC 업데이트를 한 번 돌려보려다가 평소 없던 EXPKEYSIG나 NO_PUBKEY 오류를 만나면 꽤 당황스럽습니다.

 

👋 Network History 독자 여러분, 안녕하세요. YH입니다.

이번 주에는 GitHub CLI의 Linux 패키지 저장소 서명 키가 실제로 교체되는 시점이 지나갔습니다. 기존 PGP 키는 2026년 9월 5일 만료됐고, 오래전에 공식 APT·RPM 저장소로 gh를 설치한 시스템은 새 키링을 받지 않았다면 패키지 설치·업데이트 과정에서 서명 검증 오류를 만날 수 있습니다.

 

특히 Ubuntu·Debian 서버, 오래된 개발 VM, Docker 베이스 이미지처럼 한 번 만들어 놓고 저장소 설정을 오래 건드리지 않은 환경에서 확인할 가치가 있습니다.

 

오늘은 단순히 명령어 하나를 복사하는 대신

왜 이 오류가 생겼는지 → 내 시스템이 영향을 받는지 → 키링을 안전하게 교체하는 법 → 정상화 확인 → Docker·RPM 계열까지

순서로 정리해보겠습니다.

🚨 대표 오류

EXPKEYSIG, NO_PUBKEY, GPG check FAILED가 핵심 신호입니다.

🐧 영향 환경

공식 APT·RPM 저장소로 GitHub CLI를 설치한 일부 Linux 환경이 대상입니다.

🔑 핵심 원인

기존 저장소 서명 키가 만료됐는데 로컬 키링에 새 키가 없는 경우입니다.

✅ 해결 방향

서명 검증을 끄지 말고 GitHub 공식 키링을 새로 받아 검증하는 것이 핵심입니다.

핵심 한 줄

APT 서명 오류를 우회하지 말고, GitHub 공식 새 PGP 키를 신뢰하도록 로컬 키링을 갱신하세요.

---

지금 보이는 오류가 이번 키 교체 문제인지 먼저 확인하세요

GitHub는 2026년 9월 3일 Changelog에서 Linux용 GitHub CLI 패키지 저장소의 기존 PGP 키가 9월 5일 만료된다고 다시 공지했습니다.

기존 키의 fingerprint는 2C6106201985B60E6C7AC87323F3D4EA75716059, 새 키는 7F38BBB59D064DBCB3D84D725612B36462313325입니다.

아래 오류가 보인다면 이번 키 교체와 관련됐을 가능성이 높습니다.

The following signatures were invalid:
EXPKEYSIG 23F3D4EA75716059 GitHub CLI

The following signatures couldn't be verified:
NO_PUBKEY 5612B36462313325

RPM 계열에서는 Signature verification failed, GPG check FAILED, 알 수 없는 key 관련 메시지로 나타날 수 있습니다.

중요한 점은 gh 명령 자체가 갑자기 망가진 것이 아니라는 것입니다.

이미 설치된 실행 파일은 정상 동작할 수 있지만, 패키지 관리자가 저장소 메타데이터와 새 패키지의 서명을 검증하지 못하면서 apt update, apt install gh, dnf update gh 같은 과정이 실패할 수 있습니다.

---

모든 GitHub CLI 사용자가 영향을 받는 것은 아닙니다

먼저 자신이 어떤 방식으로 GitHub CLI를 설치했는지 구분해야 합니다.

설치 환경	이번 키 교체 영향	확인 포인트
APT 공식 저장소	영향 가능	2026년 4월 8일 이전 설치 후 저장소 설정을 갱신하지 않았다면 확인
DNF / YUM / Zypper 공식 저장소	영향 가능	로컬 RPM keyring에 새 키가 있는지 확인
Docker 이미지	영향 가능	오래된 레이어에 GitHub CLI 저장소와 키링이 고정돼 있는지 확인
Windows / macOS	이번 공지 대상 아님	이 Linux 저장소 PGP 키 문제와는 별개
Homebrew / Conda / Releases 바이너리	이번 공지 대상 아님	GitHub 공식 APT·RPM 저장소 키를 사용하지 않음

2026년 4월 8일 이후 공식 Linux 설치 절차를 다시 실행했다면?

GitHub는 4월 8일부터 기존 키와 새 키를 함께 포함한 업데이트된 keyring을 배포했습니다. 따라서 그 이후 공식 설치 절차를 사용했다면 보통 새 키가 이미 들어 있습니다.

📌 설치 날짜가 기억나지 않는다면 추측하지 말고 로컬 keyring을 직접 확인하는 것이 가장 빠릅니다.

---

Ubuntu·Debian에서는 keyring과 signed-by 경로부터 확인합니다

가장 먼저 APT가 실제로 어느 keyring 파일을 바라보고 있는지 확인하겠습니다.

현재 GitHub 공식 설치 문서는 /etc/apt/keyrings/githubcli-archive-keyring.gpg를 권장하지만, 예전 설치에서는 /usr/share/keyrings/ 아래를 사용했을 수 있습니다.

저장소 설정 확인

cat /etc/apt/sources.list.d/github-cli.list

출력에서 signed-by= 뒤에 적힌 경로를 봅니다.

여기서 경로를 확인하지 않고 새 keyring만 다른 폴더에 저장하면 오류가 그대로 남을 수 있습니다.

APT source의 signed-by 경로와 실제로 갱신한 keyring 경로가 같아야 합니다.

현재 keyring 확인

gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg

파일이 없다면 예전 경로도 확인합니다.

gpg --show-keys /usr/share/keyrings/githubcli-archive-keyring.gpg

새 fingerprint인 아래 값이 함께 보이면 업데이트된 keyring을 가지고 있는 것입니다.

7F38BBB59D064DBCB3D84D725612B36462313325

반대로 기존 키만 있고 새 키가 없다면 다음 단계에서 공식 keyring을 다시 받습니다.

---

APT 사용자는 공식 keyring을 교체한 뒤 다시 업데이트합니다

GitHub가 안내한 Debian·Ubuntu 기준 해결 절차입니다.

1

keyring 디렉터리 확인
권장 경로를 사용하는 경우 `/etc/apt/keyrings`를 준비합니다.

sudo mkdir -p -m 755 /etc/apt/keyrings

2

GitHub 공식 keyring 다시 받기
GitHub CLI 공식 도메인에서 최신 keyring 파일을 내려받습니다.

sudo curl -fsSL \
  -o /etc/apt/keyrings/githubcli-archive-keyring.gpg \
  https://cli.github.com/packages/githubcli-archive-keyring.gpg

sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg

3

새 키가 실제로 들어왔는지 확인
명령이 성공했다는 사실보다 fingerprint를 확인하는 것이 중요합니다.

gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg

4

APT 갱신 및 GitHub CLI 업데이트
서명 오류가 사라졌는지 확인합니다.

sudo apt update
sudo apt install gh

정상화 기준

apt update에서 GitHub CLI 저장소의 EXPKEYSIG 또는 NO_PUBKEY 오류가 사라지고, gh --version이 정상 출력되면 기본 복구는 끝났다고 볼 수 있습니다.

gh --version

---

RPM·Docker 환경은 복구 위치가 조금 다릅니다

같은 원인이어도 배포판과 이미지 빌드 구조에 따라 고쳐야 할 위치가 다릅니다.

APT 계열

signed-by가 가리키는 keyring을 최신 공식 파일로 교체한 뒤 apt update를 다시 실행합니다.

오류 확인 → 설치 방식 확인 → keyring 경로 확인 → 공식 키 갱신 → 패키지 업데이트 검증

---

서명 검증을 끄는 방식은 해결책이 아닙니다

급하게 빌드를 살리려고 검색하다 보면 저장소를 신뢰 대상으로 강제로 지정하거나 GPG 검사를 끄는 우회 방법을 접할 수 있습니다.

하지만 패키지 서명은 “내가 받는 저장소 메타데이터와 패키지가 신뢰한 배포자의 것인지” 확인하는 안전장치입니다.

다음 방향은 피하는 것이 좋습니다.

trusted=yes 같은 방식으로 저장소 검증을 우회하거나, RPM의 GPG 검증 자체를 꺼버리는 방법입니다.

오류를 없애는 것과 서명 검증을 정상화하는 것은 전혀 다른 문제입니다.

이번 문제의 정상적인 해결은 검증 기능을 제거하는 게 아니라 GitHub가 발표한 새 공개키를 로컬 시스템이 올바르게 신뢰하도록 만드는 것입니다.

운영 서버나 CI 이미지라면 공식 keyring URL뿐 아니라 fingerprint까지 확인해두면 나중에 비슷한 키 교체가 있을 때 대응하기 쉽습니다.

---

다음부터는 이미지와 서버에 ‘키 만료’도 관리 항목으로 넣어두세요

패키지 저장소의 PGP 키 교체는 GitHub CLI만의 이야기는 아닙니다.

오래된 서버 이미지나 Dockerfile은 애플리케이션 버전뿐 아니라 저장소 URL, keyring 파일, 인증서 같은 신뢰 정보까지 함께 오래될 수 있습니다.

🧱 Golden Image

오래된 VM 템플릿을 주기적으로 새로 빌드해 저장소 설정도 갱신합니다.

🐳 Docker

장기간 캐시된 베이스 레이어가 오래된 keyring을 품고 있지 않은지 확인합니다.

🔐 Fingerprint

키 교체 공지가 나오면 공식 문서의 fingerprint와 실제 keyring을 비교합니다.

🧪 검증

복구 후에는 명령 성공뿐 아니라 패키지 저장소 서명 오류가 사라졌는지 확인합니다.

오늘 한 번만 확인해도 좋은 서버

2026년 4월 이전에 만들어 놓은 Ubuntu 개발 VM, 장기간 재빌드하지 않은 CI 이미지, GitHub CLI를 사전 설치한 사내 Golden Image가 있다면 keyring 상태를 확인해볼 만합니다.

---

마무리

이번 GitHub CLI 문제는 프로그램 자체의 장애라기보다 패키지 저장소를 신뢰하는 PGP 키가 교체되면서 생기는 검증 문제에 가깝습니다.

따라서 오류 메시지에 EXPKEYSIG나 NO_PUBKEY가 보인다면 무작정 GitHub CLI를 지우기 전에, APT source의 signed-by 경로와 keyring fingerprint부터 확인해보세요.

✅ 오늘 서버 한 대만 점검한다면 아래 명령부터 실행해보면 됩니다.

cat /etc/apt/sources.list.d/github-cli.list
gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg

👋 Network History의 YH였습니다.
다음에도 갑자기 뜬 오류 메시지를 그냥 지우는 방법이 아니라, 원인을 확인하고 정상 상태까지 검증하는 순서로 정리해보겠습니다.

※ 본문 명령은 2026년 9월 10일 기준 GitHub CLI 공식 문서를 바탕으로 정리했습니다. Linux 배포판, 기존 저장소 설정, keyring 경로가 다를 수 있으므로 실제 변경 전 현재 설정을 확인하세요. 본문은 서명 검증을 비활성화하는 우회 방법을 권장하지 않습니다.

---

🔗 공식 출처

📢 GitHub Changelog 🔑 PGP Key Rotation 안내 🐧 GitHub CLI Linux 설치 문서