Ubuntu에서 GPG 오류 "다음 서명을 확인할 수 없습니다"를 해결하는 방법

먼저 경고를 발생시킨 저장소를 확인한 다음 해당 저장소의 키 또는 구성을 수정하십시오. APT 서명 검사를 비활성화하지 마십시오. " 다음 서명을 확인할 수 없습니다"라는 메시지는 APT가 저장소 메타데이터가 신뢰하는 키로 서명되었는지 확인할 수 없음을 의미합니다. 서명이 확인될 때까지 APT는 해당 소스를 사용하지 않을 수 있습니다. 임의의 키를 추가하거나 소스를 신뢰할 수 있는 것으로 설정하면 경고가 표시되지 않지만, 경고가 제공해야 하는 보호 기능이 제거됩니다.

예를 들어, 브라우저 공급업체 저장소에 대한 sudo apt update보고서는 NO_PUBKEY문제가 있지만 우분투 자체 아카이브 라인은 성공적으로 업데이트되는 경우를 가정해 보겠습니다. 이 경우 해결 방법은 해당 공급업체가 현재 공개한 서명 키를 설치하고 해당 저장소에 적용하는 것입니다. 우분투 아카이브 키링을 다시 설치하는 것은 타사 키 문제를 해결하지 못합니다. 아래 명령은 템플릿입니다. 예제 저장소 세부 정보는 소프트웨어 게시자의 공식 지침에 따른 값으로 바꿔야 합니다.

키를 변경하기 전에 정확한 오류 메시지를 확인하세요.

업데이트 명령을 실행하고 출력 줄에 표시되는 저장소 URL과 오류 코드를 기록해 두세요.

sudo apt update

APT는 일반적으로 URL과 릴리스 모음(예: noble또는 ) 으로 소스를 식별합니다 jammy. 둘 이상의 소스가 구성된 경우 여러 오류가 표시될 수 있습니다. 변경하기 전에 각 메시지를 해당 저장소와 연결하십시오. 이러한 일반적인 오류 메시지는 서로 다른 원인을 나타냅니다.

메시지 또는 단서아마도 의미는?첫 번째 조치
NO_PUBKEY해당 저장소에 필요한 공개 서명 키를 APT에서 사용할 수 없거나 소스가 키 파일을 가리키지 않습니다.저장소 소유자를 확인하고 공식 게시자 지침에 따라 현재 키를 얻으십시오.
EXPKEYSIG서명에 사용된 키가 만료되었거나 저장소의 서명 설정을 업데이트해야 합니다.퍼블리셔의 최신 키 순환 공지를 확인하세요. 만료된 키를 계속해서 재설치하지 마세요.
BADSIG서명이 APT가 수신한 메타데이터와 일치하지 않습니다. 오래된 미러, 프록시, 부분 다운로드 또는 저장소 측 문제가 원인일 수 있습니다.소스, 네트워크 경로 및 캐시된 인덱스 파일을 확인한 후 다시 시도하십시오.
Release file is not valid yet또는 이와 유사한 시간 관련 표현시스템 시계가 저장소의 서명된 타임스탬프보다 뒤쳐져 있을 수 있습니다.시스템 날짜, 시간대 및 시간 동기화 상태를 확인하십시오.
키는 존재하지만 소스에서는 여전히 알 수 없는 키라고 보고합니다.해당 소스는 다른 키링, 잘못된 경로 또는 APT에서 읽을 수 없는 키 파일을 참조할 수 있습니다.소스의 Signed-By설정과 키링 권한을 확인하십시오.

오류 메시지에 시간이 언급되면 먼저 시스템 시계를 확인하십시오.

서명 및 저장소 메타데이터에는 유효 기간이 있습니다. 이전 스냅샷에서 복원된 서버, 듀얼 부팅 컴퓨터 또는 시간 서비스에 오류가 발생한 시스템의 경우 시스템 시간이 크게 어긋나 현재 메타데이터가 유효하지 않은 것처럼 보일 수 있습니다. 시스템 시간을 확인하십시오.

timedatectl status

표시된 날짜와 시간이 정확한지, 그리고 시간 동기화가 활성화되어 있는지 확인하십시오. 시계가 잘못된 경우 호스트의 시간 서비스를 수정하거나 구성된 네트워크 시간 동기화 방법을 활성화한 후 다시 시도하십시오 sudo apt update. 대략적인 날짜를 수동으로 설정하지 마십시오. 시계는 실제 시간을 반영해야 합니다. 시간 수정은 누락되었거나 만료된 저장소 키를 복구하지 않으므로, 메시지가 계속 오류로 표시되는 경우 NO_PUBKEY관련 EXPKEYSIG키 단계를 진행하십시오.

누락되었거나 만료된 타사 저장소 키를 수정하세요.

Ubuntu의 현재 지침은 타사 키를 전용 키링에 저장하고 해당 소스에서 해당 키를 참조하도록 권장합니다 . 이렇게 하면 해당 저장소를 인증할 수 있는 키가 제한됩니다. Ubuntu는 타사 저장소 가이드 에서 이 접근 방식을 설명하고 있으며 , APT는 sources.list 매뉴얼 에서 범위 검증 방법을 Signed-By설명합니다 .Signed-By

1. 오류를 발생시킨 원인을 찾으세요

저장소 항목을 나열하고 APT 출력에 표시된 호스트를 검색합니다.

grep -RniE '^[[:space:]]*(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Ubuntu 24.04 이상 버전에서는 일반적으로 .deb822 확장자를 가진 deb822 파일을 사용하고 .sources, 이전 버전에서는 일반적으로 .deb822 확장자를 가진 한 줄짜리 파일을 사용합니다 .list. Ubuntu 패키지 관리 설명서에서 이러한 소스 형식을 확인할 수 있습니다. 관련 없는 벤더 저장소를 수정하기 위해 Ubuntu 아카이브 항목을 편집하지 마십시오.

2. 게시자의 최신 키를 가져와서 확인합니다.

소프트웨어 게시자의 공식 저장소 설정 페이지를 열고 저장소 URL, 지원되는 Ubuntu 릴리스, 서명 키 다운로드 위치 및 전체 키 지문이 명시되어 있는지 확인하십시오. 게시자가 지정한 출처에서만 키를 다운로드하십시오. 쉼표 뒤에 표시되는 짧은 16진수 ID뿐만 아니라 전체 지문을 비교하십시오 NO_PUBKEY. APT 보안 매뉴얼에서는 신뢰할 수 있는 채널을 통해 키를 획득할 것을 강조합니다. 잘못된 키를 신뢰하면 저장소 검증이 무의미해집니다.

다음 예제에서는 ASCII로 보호된 키를 사용합니다. 예제 URL과 파일 이름을 게시자의 공식 값으로 바꾸십시오.

curl -fsSLo /tmp/vendor-archive.asc https://packages.vendor.example/ubuntu/archive-key.asc
gpg --show-keys --with-fingerprint /tmp/vendor-archive.asc

표시된 지문이 게시자가 문서화한 지문과 일치하는 경우에만 진행하십시오. 해당 지문을 바이너리 키링으로 변환하여 APT의 로컬 키링 디렉터리에 저장하십시오.

sudo install -d -m 0755 /etc/apt/keyrings
gpg --dearmor --output /tmp/vendor-archive.gpg /tmp/vendor-archive.asc
sudo install -m 0644 /tmp/vendor-archive.gpg /etc/apt/keyrings/vendor-archive-keyring.gpg

예시 도메인은 설명 목적으로 제공되며 실제 공급업체 키를 다운로드하지 않습니다. 실제 소프트웨어 게시자가 제공하는 정확한 인증 키 URL을 사용하십시오. 키 소유권 확인을 위해 키 서버 검색 결과를 사용하지 마십시오.

3. 저장소 소스에서 키의 범위를 지정합니다.

한 줄로 .list입력하는 경우 패턴은 다음과 같습니다.

deb [signed-by=/etc/apt/keyrings/vendor-archive-keyring.gpg] https://packages.vendor.example/ubuntu noble main

deb822 .sources파일의 경우 해당 필드는 다음과 같습니다.

Types: deb
URIs: https://packages.vendor.example/ubuntu
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive-keyring.gpg

이것들은 템플릿일 뿐, 보편적으로 유효한 소스 항목이 아닙니다. 공급업체의 공식 설치 지침에 있는 URI, 스위트 및 구성 요소를 그대로 사용하십시오. 잘못된 Ubuntu 코드명은 키가 유효하더라도 패키지 충돌을 일으킬 수 있습니다. 키링 경로가 설치한 파일과 일치하는지 확인하십시오. 키링은 APT의 권한이 없는 _apt사용자가 읽을 수 있어야 하므로 예제에서는 모드로 설치합니다 0644. 동일한 저장소에 대한 중복 항목을 제거하거나 수정하여 범위가 지정되지 않은 이전 항목으로 인해 경고가 계속 발생하는 것을 방지하십시오.

APT apt-key명령어는 일반적인 저장소 설정에는 더 이상 사용되지 않습니다. 타사 키를 전역적으로 추가 apt-key adv하거나 모든 공급업체 키를 공통 신뢰 키링에 배치하는 가이드는 피하십시오. 범위가 지정된 Signed-By항목을 사용하면 신뢰 관계가 명확해지고 하나의 저장소 키만 신뢰하는 것의 영향을 줄일 수 있습니다.

경고 메시지가 우분투 자체 아카이브에 대한 것이라면

먼저 저장소 구성이 설치된 Ubuntu 릴리스와 일치하는지, 시스템 시계가 정확한지 확인하십시오. Ubuntu 아카이브 서명 키는 패키지에 포함되어 있습니다 ubuntu-keyring. 설치된 키링이 손상되었거나 오래된 경우, APT가 유효하게 구성된 Ubuntu 소스에서 패키지를 다운로드하고 확인할 수 있다면 다음 명령으로 다시 설치하십시오.

sudo apt install --reinstall ubuntu-keyring

그런 다음 다시 실행하십시오 sudo apt update. 오류가 발생하는 유일한 원인이 오래된 릴리스 아카이브 또는 일관되지 않은 메타데이터를 제공하는 미러인 경우 키링을 다시 설치해도 문제가 해결되지 않을 수 있습니다. 키를 변경하기 전에 Ubuntu의 릴리스 지원 및 저장소 구성을 확인하십시오. 관련 없는 사이트에서 다운로드한 키로 Ubuntu 아카이브 키를 교체하거나 업데이트를 강제로 실행하기 위해 검증을 비활성화하지 마십시오.

메타데이터 불일치가 있는 경우에만 캐시된 인덱스를 지웁니다.

BADSIG일시적인 네트워크 중단이나 미러/프록시 문제 발생 후 APT가 보고하는 경우 , 로컬에 캐시된 패키지 목록이 불완전하거나 일관성이 없을 수 있습니다. 구성된 소스가 정상인지 확인한 후, 캐시된 APT 인덱스 파일만 삭제하고 다시 가져오십시오.

sudo rm -rf /var/lib/apt/lists/*
sudo apt update

이 작업은 다운로드된 저장소 인덱스를 제거하는 것이지 설치된 패키지를 제거하는 것은 아닙니다. APT는 다음 업데이트 시 인덱스를 다시 생성합니다. 만약 BADSIG즉시 오류가 발생하면, 정리 작업을 반복하지 마십시오. 네트워크 프록시, 캐싱 게이트웨이 또는 미러가 일치하지 않는 메타데이터를 덮어쓰거나 제공하고 있는지 확인하고, 저장소 게시자에게 저장소 상태를 확인하십시오. 인덱스를 반복적으로 삭제하는 것은 저장소 자체에서 잘못 게시한 서명 문제를 해결하지 못합니다.

수리를 확인하고 보호 기능을 활성화 상태로 유지하십시오.

다시 실행하여 sudo apt update해당 저장소가 NO_PUBKEY, EXPKEYSIG, BADSIG, 또는 서명 검증 경고 없이 완료되는지 확인하십시오. 그런 다음 해당 소스에서 패키지를 확인하고 apt-cache policy package-name, 이름을 실제 패키지 이름으로 바꾸십시오. 설치 또는 업그레이드하기 전에 후보 버전이 예상 저장소에서 가져온 것인지 확인하십시오.

trusted=yes`--`, allow-insecure=yes`--`, --allow-unauthenticated`--` 또는 이와 유사한 옵션을 영구적인 해결책으로 사용하지 마십시오 . APT의 서명 검사는 저장소 메타데이터가 사용자가 신뢰하도록 선택한 키로 서명되었는지 확인합니다. 이 기능을 비활성화하면 APT에서 더 이상 무결성 검사를 제공할 수 없습니다. APT 보안 설명서 에서 아카이브 인증 체인과 그 한계를 확인할 수 있습니다. 게시자가 저장소를 철회했거나, 메타데이터 서명을 중단했거나, 검증 가능한 키 지문을 제공하지 않는 경우, 검증을 우회하는 대신 해당 소스를 제거하거나 비활성화하십시오.

본 문서는 2026년 10월 6일에 확인되었습니다. Ubuntu 저장소 형식 및 키 관리 권장 사항은 릴리스 버전에 따라 다를 수 있으므로, 설치된 Ubuntu 버전의 문서와 저장소 게시자의 최신 지침을 참조하십시오.

댓글 남기기

Ubuntu에서 GPG 오류 "다음 서명을 확인할 수 없습니다"를 해결하는 방법

Ubuntu에서 GPG 오류 "다음 서명을 확인할 수 없습니다"를 해결하는 방법

Ubuntu APT 서명 오류를 안전하게 수정하세요. 패키지 검증을 비활성화하지 않고도 NO_PUBKEY, EXPKEYSIG, BADSIG, 클럭 및 저장소 구성 문제를 식별할 수 있습니다.

SLES 15에서 DM-Multipath를 구성하는 방법: 실용적인 가이드

SLES 15에서 DM-Multipath를 구성하는 방법: 실용적인 가이드

안전한 검색, 서비스 설정, 최소한의 multipath.conf 변경, initramfs 업데이트 및 경로 상태 확인을 통해 SLES 15에서 DM-Multipath를 구성합니다.

SLES Btrfs Snapper 업데이트 실패 후 롤백: 안전한 복구 가이드

SLES Btrfs Snapper 업데이트 실패 후 롤백: 안전한 복구 가이드

Btrfs 및 Snapper를 사용하여 업데이트 실패 후 SLES를 복구하세요. 롤백 옵션을 비교하고, 스냅샷을 안전하게 테스트하고, 시스템을 복원하고, 저장소를 검증하세요.

Pardus 클라이언트 전체에 사용자 지정 배경 화면 및 정책을 배포하는 방법

Pardus 클라이언트 전체에 사용자 지정 배경 화면 및 정책을 배포하는 방법

Liderahenk와 Ahenk를 사용하여 사용자 지정 Pardus GNOME 배경화면을 설정하고, dconf로 선택한 설정을 잠그고, 테스트를 거친 파일럿 환경을 통해 다른 클라이언트 정책을 배포하세요.

우분투 서버 비상 모드 부팅: 단계별 복구 가이드

우분투 서버 비상 모드 부팅: 단계별 복구 가이드

우분투 서버가 비상 모드로 진입한 이유를 진단하고, 일반적인 /etc/fstab 및 마운트 문제를 안전하게 복구하고, 파일 시스템을 검사하고, 정상적인 재부팅을 확인합니다.

Ubuntu 24.04에서 Flatpak 앱이 GTK 테마를 제대로 적용하지 않는 문제 해결

Ubuntu 24.04에서 Flatpak 앱이 GTK 테마를 제대로 적용하지 않는 문제 해결

Ubuntu 24.04에서 GTK 테마를 무시하는 Flatpak 앱 문제를 해결하세요. 테마 확장 프로그램, GTK 포털, 밝은/어두운 설정, 앱 툴킷 제한 사항을 확인하십시오.

Pardus 엔터프라이즈 관리 소프트웨어(LIDER AHENK) 구성 방법

Pardus 엔터프라이즈 관리 소프트웨어(LIDER AHENK) 구성 방법

Pardus에서 LIDER AHENK를 품질 중심 설정으로 구성하십시오. 필수 조건을 확인하고, Lider를 배포하고, Ahenk 클라이언트를 등록하고, 관리를 검증하십시오.

Pardus 23 워크스테이션에서 NVIDIA 드라이버를 활성화하는 방법

Pardus 23 워크스테이션에서 NVIDIA 드라이버를 활성화하는 방법

Pardus NVIDIA 드라이버 설치 프로그램을 사용하여 Pardus 23에서 NVIDIA 드라이버를 활성화하세요. GPU 호환성을 확인하고, 안전하게 재부팅하고, 드라이버를 검증하고, 일반적인 문제를 해결할 수 있습니다.

우분투 서버 24.04 최소 설치 vs. 표준 설치: 성능 벤치마크 결과 비교

우분투 서버 24.04 최소 설치 vs. 표준 설치: 성능 벤치마크 결과 비교

재현 가능한 벤치마크 방법을 사용하여 Ubuntu Server 24.04 최소 설치와 표준 설치의 디스크 사용량, 메모리, 부팅 시간, 서비스 및 실제 워크로드 성능을 비교합니다.

SUSE Linux Enterprise에서 "Zypper가 다른 프로세스에 의해 잠겼습니다" 오류 해결 방법

SUSE Linux Enterprise에서 "Zypper가 다른 프로세스에 의해 잠겼습니다" 오류 해결 방법

SLES에서 Zypper 잠금 오류를 안전하게 해결합니다. 프로세스를 식별하고, 대기할지 중지할지 선택하며, 트랜잭션 잠금과 패키지 잠금을 구분합니다.