기술 · 실용 가이드
APT NO_PUBKEY 오류: 저장소를 확인하고 Signed-By로 키 설정 복구하기
실제로 활성화된 소스를 찾고 게시자와 전체 지문을 확인한다. 키 형식, _apt 접근 권한, Signed-By를 점검한 뒤 같은 저장소의 서명 검증이 복구됐는지 확인한다.
APT의 NO_PUBKEY는 저장소 메타데이터 서명에 쓰인 키를 해당 소스 설정에서 사용할 수 없다는 뜻이다. 포럼이나 키 서버에서 찾은 키가 올바르다는 증거도, 서명 검사를 끌 이유도 아니다.
안전한 복구는 저장소별로 진행한다. 오류를 보관하고 정확한 소스를 찾은 다음, 게시자의 공식 경로로 운영자와 전체 지문을 확인한다. 올바른 형식의 전용 키링을 Signed-By로 연결하고 인증 우회 옵션 없이 같은 업데이트를 다시 실행한다.
1. 신뢰 설정을 바꾸기 전에 오류 보관
일반 업데이트를 다시 실행해 전체 출력을 보관한다. NO_PUBKEY 식별자, 저장소 URL, suite 또는 코드명, InRelease와 Release.gpg 중 어느 파일이 언급됐는지 기록한다. 아직 키를 추가하지 않는다. 여러 제삼자 소스에서 무관한 경고가 나올 수 있으므로 메시지 순서가 아니라 호스트명과 suite로 대상을 찾는다.
/etc/apt/sources.list와 /etc/apt/sources.list.d 안에서 APT가 인식하는 .list 및 .sources 파일을 살핀다. URIs, Suites, Signed-By, Enabled를 포함한 전체 행이나 deb822 단락을 읽는다. 주석 처리된 .list 행과 Enabled: no 단락은 비활성이고, 다른 확장자의 백업도 활성 항목이 아니다. 오류 URL과 suite를 대조하고 활성 중복 항목을 모두 기록한다. 재귀 검색은 위치를 찾는 보조 수단이지 APT가 읽었다는 증거가 아니다.
2. 배포판 공식 저장소와 제삼자 저장소 구분
기본 Debian과 Ubuntu 설치에는 배포판이 관리하는 키링 패키지로 공식 저장소 키가 제공된다. 공식 저장소의 키가 없으면 오래된 키링, 지원이 끝난 릴리스, 잘못된 소스 항목, 손상된 설치 등이 원인일 수 있다. 직접 키를 내려받기 전에 OS 릴리스와 공식 URL을 확인한다.
제삼자 저장소는 공급업체의 공식 설정 페이지나 키 배포 문서를 사용한다. URL, 게시자 신원, 공개된 전체 지문을 독립적으로 연결할 수 없다면 해당 소스를 끄고 멈춘다. 임의의 키를 가져오면 오류가 달라질 수는 있지만 누가 저장소를 통제하는지 입증하지는 못한다.
3. 설치 전에 전체 지문 대조
확인된 게시자 경로에서만 후보 공개키를 임시 파일로 받는다. `gpg --show-keys --with-fingerprint --with-subkey-fingerprint /path/to/candidate-key`로 내용을 보고 신뢰된 키링에는 추가하지 않는다. 기본키의 전체 지문을 소유자가 별도의 공식 페이지에 공개한 값과 문자 하나씩 대조한다.
끝의 8자리나 16자리가 NO_PUBKEY와 같다는 이유로 승인하지 않는다. 키 서버 검색, 포럼 명령, 리디렉션, 익숙한 사용자 ID도 게시자 확인을 대신하지 않는다. 공식 문서가 키 교체를 알렸다면 이전·새 지문과 적용되는 지침을 먼저 기록한다.
4. 올바른 형식의 전용 키링 준비
필요하면 /etc/apt/keyrings를 만들고 root 소유와 디렉터리 통과 권한을 설정한다. ASCII armor 공개키는 .asc, 내보낸 바이너리 OpenPGP 키링은 .gpg를 쓴다. Debian 문서는 현대 GnuPG keybox와 APT 키링을 구분한다. 개인 GnuPG 홈이나 keybox 파일을 이 디렉터리에 복사하지 않는다.
지문 확인 후 공개키 자료만 저장소별 파일명으로 설치하고 root 소유, 모드 0644를 설정한다. file, gpg --show-keys --with-fingerprint, stat 및 `sudo -u _apt test -r /etc/apt/keyrings/vendor-archive-keyring.asc`로 확인한다. 마지막 검사가 실패하면 namei -l로 모든 상위 디렉터리를 살핀다. 파일이 읽혀도 상위 디렉터리를 통과할 수 없으면 _apt는 접근하지 못한다.
5. Signed-By로 저장소의 키 제한
deb822 .sources에서는 확인한 URI와 suite 단락에 `Signed-By: /etc/apt/keyrings/vendor-archive-keyring.asc`를 넣는다. 이전 .list 형식에서는 deb 바로 뒤 옵션 대괄호에 `signed-by=/etc/apt/keyrings/vendor-archive-keyring.asc`를 넣는다. 실제 설치한 .asc 또는 .gpg 이름을 사용하고 확장자를 키 표현 형식에 맞춘다.
Signed-By는 이 저장소를 인증할 수 있는 키를 제한한다. 모든 제삼자 키를 전역 신뢰에 넣는 것보다 범위가 좁지만 패키지가 무해하다고 보증하지는 않는다. 한 저장소씩 옮기고 원본 설정을 보관하며, 제한된 소스의 검증이 성공하기 전에는 기존 전역 키를 지우지 않는다. 파일에 여러 공개키가 있고 지문 선택자가 없으면 그 키들이 모두 허용된다. 전체 파일을 확인하고 게시자가 설명한 선택 방법을 따르며, 출처가 불분명한 키 묶음을 신뢰하지 않는다.
6. 종료 코드보다 저장소 검증 결과 확인
불안전한 옵션 없이 `sudo apt-get update`를 실행한다. 대상 저장소의 메타데이터가 내려받아져 인증되고 NO_PUBKEY, 잘못된 서명, 읽을 수 없는 키링 메시지가 사라져야 한다. 성공한 호스트명과 suite가 처음 대상과 일치하는지 확인한다. 다른 미러의 성공은 원래 실패 항목의 복구를 입증하지 않는다.
해당 저장소에서 받을 패키지에 `apt-cache policy PACKAGE_NAME`을 실행해 후보 버전과 출처를 확인한다. 소스 파일 경로, 저장소 URI와 suite, 확인된 전체 지문, 설치한 키링 경로와 SHA-256, 파일 모드, 업데이트 결과, 패키지 출처 검사를 기록한다. 나중의 키 교체나 사고 검토에 문서 없는 가져오기 명령보다 도움이 된다.
7. 인증을 낮추지 말고 실패 원인 점검
지문 불일치, 공식 페이지 접근 불가, 문서화된 교체키 없는 만료·폐기, 갑작스러운 저장소 신원 변경이면 사용을 멈추고 게시자에게 문의한다. 지문이 맞는데 NO_PUBKEY가 계속되면 Signed-By 경로, 형식, _apt 읽기 권한, 중복 소스, Release 메타데이터가 실제로 그 키로 서명됐는지 다시 살핀다.
trusted=yes, allow-insecure=yes, Acquire::AllowInsecureRepositories나 인증 없는 설치는 문제를 드러낸 검사를 약화한다. Debian은 이를 보안 수준을 낮추는 예외로 설명하며 키 복구 단계로 제시하지 않는다. 게시자, 키, 서명된 메타데이터의 연결을 검증할 때까지 저장소를 비활성 상태로 둔다.
