Jak naprawić błąd GPG: następujących podpisów nie można zweryfikować w systemie Ubuntu

Zacznij od zidentyfikowania repozytorium, które spowodowało ostrzeżenie, a następnie popraw klucz lub konfigurację tego repozytorium. Nie wyłączaj sprawdzania podpisów APT. Komunikat „Następujących podpisów nie można zweryfikować” oznacza, że ​​APT nie może potwierdzić, że metadane repozytorium zostały podpisane kluczem, któremu ufa. Dopóki podpis nie zostanie zweryfikowany, APT może odmówić użycia tego źródła. Dodanie losowego klucza lub ustawienie źródła jako zaufanego może ukryć ostrzeżenie, jednocześnie pozbawiając je ochrony, którą ma ono zapewniać.

Załóżmy na przykład, że sudo apt updateraporty NO_PUBKEYdla repozytorium dostawcy przeglądarki są aktualizowane, podczas gdy wiersze archiwum Ubuntu są aktualizowane pomyślnie. Prawdopodobnym rozwiązaniem jest zainstalowanie aktualnie opublikowanego klucza podpisu tego dostawcy i przypisanie go do tego repozytorium. Ponowna instalacja zestawu kluczy archiwum Ubuntu nie rozwiąże problemu z kluczami innych firm. Poniższe polecenia to szablony: zastąp szczegóły przykładowego repozytorium wartościami z oficjalnych instrukcji wydawcy oprogramowania.

Przed zmianą kluczy przeczytaj dokładny błąd

Uruchom polecenie aktualizacji i zanotuj adres URL repozytorium oraz kod błędu w tych samych wierszach wyników:

sudo apt update

APT zazwyczaj identyfikuje źródło na podstawie adresu URL i pakietu wydań, takiego jak noblelub jammy. Jeśli skonfigurowano więcej niż jedno źródło, może wyświetlić kilka błędów. Przed wprowadzeniem zmiany należy dopasować każdą wiadomość do jej własnego repozytorium. Te typowe sygnatury wskazują na różne przyczyny:

Najpierw sprawdź zegar systemowy, gdy błąd wspomina o czasie

Podpisy i metadane repozytorium mają okresy ważności. Serwer przywrócony ze starej migawki, komputer z podwójnym rozruchem lub maszyna z uszkodzoną usługą czasu mogą mieć zegar na tyle niedokładny, że bieżące metadane mogą wydawać się nieprawidłowe. Sprawdź czas systemowy:

timedatectl status

Sprawdź, czy wyświetlana data i godzina są prawidłowe, a synchronizacja czasu jest aktywna. Jeśli zegar jest nieprawidłowy, popraw usługę czasu hosta lub włącz skonfigurowaną metodę synchronizacji czasu sieciowego, a następnie spróbuj ponownie sudo apt update. Unikaj ręcznego ustawiania przybliżonej daty: zegar powinien odzwierciedlać czas rzeczywisty. Korekta czasu nie naprawi brakującego lub wygasłego klucza repozytorium, więc jeśli komunikat nadal wyświetla błąd NO_PUBKEYlub EXPKEYSIGbłąd, kontynuuj wykonywanie odpowiednich kroków dotyczących klucza.

Napraw brakujący lub wygasły klucz repozytorium innej firmy

Aktualne wytyczne Ubuntu zalecają przechowywanie kluczy zewnętrznych w dedykowanym pęku kluczy i odwoływanie się do niego z odpowiedniego źródła za pomocą Signed-By. To ogranicza liczbę kluczy, które mogą uwierzytelniać dane repozytorium. Ubuntu opisuje to podejście w swoim przewodniku po repozytoriach zewnętrznych , a APT dokumentuje Signed-Byweryfikację zakresów w podręczniku sources.list .

1. Znajdź źródło, które wygenerowało błąd

Wyświetl listę wpisów w repozytorium i wyszukaj hosta pokazanego w wynikach APT:

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

Ubuntu 24.04 i nowsze wersje często używają plików deb822 z końcówką .sources; starsze wersje często używają plików jednowierszowych z końcówką .list. Dokumentacja zarządzania pakietami Ubuntu opisuje te formaty źródłowe. Nie edytuj wpisu w archiwum Ubuntu, aby naprawić niepowiązane repozytorium dostawcy.

2. Pobierz i zweryfikuj aktualny klucz wydawcy

Otwórz oficjalną stronę konfiguracji repozytorium wydawcy oprogramowania i sprawdź, czy zawiera ona adres URL repozytorium, obsługiwaną wersję Ubuntu, lokalizację do pobrania klucza podpisu oraz pełny odcisk klucza. Pobieraj klucz tylko ze źródła wskazanego przez wydawcę. Porównaj pełny odcisk klucza, a nie tylko krótki identyfikator szesnastkowy wyświetlany po NO_PUBKEY. Podręcznik bezpieczeństwa APT podkreśla, że ​​klucze są uzyskiwane za pośrednictwem zaufanego kanału; zaufanie niewłaściwemu kluczowi podważyłoby weryfikację repozytorium.

W poniższym przykładzie użyto klucza ASCII. Zastąp przykładowy adres URL i nazwę pliku oficjalnymi wartościami wydawcy:

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

Kontynuuj tylko wtedy, gdy wyświetlony odcisk palca będzie zgodny z tym udokumentowanym przez wydawcę. Przekonwertuj go na binarny pęk kluczy i umieść w lokalnym katalogu pęku kluczy 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

Domena przykładowa ma charakter poglądowy i nie spowoduje pobrania prawdziwego klucza dostawcy. Użyj dokładnego, zweryfikowanego adresu URL klucza dostarczonego przez wydawcę oprogramowania. Nie używaj wyników wyszukiwania serwera kluczy jako substytutu potwierdzenia własności klucza.

3. Określ zakres klucza w źródle repozytorium

W przypadku wpisu jednowierszowego .listwzór jest następujący:

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

W przypadku pliku deb822 .sourcesodpowiednie pola wyglądają następująco:

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

To są szablony, a nie uniwersalne wpisy źródłowe. Zachowaj URI, pakiet i komponenty z oficjalnych instrukcji instalacji dostawcy; nieprawidłowa nazwa kodowa Ubuntu może powodować konflikty pakietów, nawet jeśli klucz jest prawidłowy. Upewnij się, że ścieżka do pliku kluczy jest zgodna z zainstalowanym plikiem. Plik kluczy musi być czytelny dla _aptużytkownika APT bez uprawnień, dlatego przykład instaluje go z trybem 0644. Usuń lub popraw zduplikowane wpisy dla tego samego repozytorium, aby stary wpis nieobjęty zakresem nie generował ostrzeżenia.

Polecenie APT apt-keyjest przestarzałe w przypadku standardowej konfiguracji repozytorium. Należy unikać poradników, które globalnie dodają klucze stron trzecich apt-key advlub umieszczają każdy klucz dostawcy we wspólnym, zaufanym pęku kluczy. Signed-ByWpis o określonym zakresie sprawia, że ​​relacja zaufania jest bardziej przejrzysta i zmniejsza efekt zaufania do jednego klucza repozytorium.

Jeśli ostrzeżenie dotyczy własnego archiwum Ubuntu

Najpierw sprawdź, czy zestaw repozytoriów jest zgodny z zainstalowaną wersją Ubuntu i czy zegar systemowy jest poprawny. Klucze podpisywania archiwum Ubuntu są dołączone do ubuntu-keyringpakietu. Jeśli zainstalowany zestaw kluczy jest uszkodzony lub nieaktualny, a APT nadal może pobrać i zweryfikować pakiety z prawidłowo skonfigurowanego źródła Ubuntu, zainstaluj go ponownie za pomocą:

sudo apt install --reinstall ubuntu-keyring

Następnie uruchom sudo apt updateponownie. Jeśli jedynym źródłem błędów jest przestarzałe archiwum wydania lub serwer lustrzany obsługujący niespójne metadane, ponowna instalacja zestawu kluczy może nie pomóc. Przed zmianą kluczy sprawdź obsługę wydań Ubuntu i konfigurację repozytorium. Nie zastępuj klucza archiwum Ubuntu kluczem pobranym z innej witryny ani nie wyłączaj weryfikacji, aby wymusić aktualizację.

Wyczyść indeksy w pamięci podręcznej tylko w przypadku niezgodności metadanych

Jeśli APT zgłasza błąd BADSIGpo chwilowej przerwie w działaniu sieci lub problemie z serwerem lustrzanym/proxy, lokalnie buforowane listy pakietów mogą być niekompletne lub niespójne. Po potwierdzeniu, że skonfigurowane źródło jest legalne, wyczyść tylko buforowane pliki indeksów APT i pobierz je ponownie:

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

Spowoduje to usunięcie pobranych indeksów repozytorium, a nie zainstalowanych pakietów. APT odbuduje indeksy przy następnej aktualizacji. Jeśli BADSIGbłąd zwróci się natychmiast, przerwij powtarzanie czyszczenia: sprawdź, czy serwer proxy sieciowy, brama buforująca lub serwer lustrzany nie nadpisuje lub nie udostępnia niezgodnych metadanych, i sprawdź status repozytorium u jego wydawcy. Wielokrotne usuwanie indeksów nie naprawia sygnatury, którą samo repozytorium publikuje nieprawidłowo.

Potwierdź naprawę i zachowaj włączoną ochronę

Uruchom sudo apt updateponownie i sprawdź, czy repozytorium, którego dotyczy problem, kończy działanie bez ostrzeżeń NO_PUBKEY, EXPKEYSIG, BADSIGlub signature-verification. Następnie sprawdź pakiet z tego źródła za pomocą apt-cache policy package-name, zastępując nazwę rzeczywistym pakietem. Przed zainstalowaniem lub uaktualnieniem upewnij się, że jego wersja kandydująca pochodzi z oczekiwanego repozytorium.

Nie używaj opcji trusted=yes, allow-insecure=yes, --allow-unauthenticatedani podobnych jako trwałego rozwiązania. Kontrola podpisu APT weryfikuje, czy metadane repozytorium są podpisane kluczem, któremu ufasz; jej wyłączenie oznacza, że ​​APT nie może już zapewnić kontroli integralności. Podręcznik APT Secure wyjaśnia łańcuch uwierzytelniania archiwum i jego ograniczenia. Jeśli wydawca wycofał repozytorium, przestał podpisywać metadane lub nie dostarcza weryfikowalnego odcisku klucza, usuń lub wyłącz to źródło zamiast pomijać weryfikację.

Dokumentacja sprawdzona 6 października 2026 r. Formaty repozytoriów Ubuntu i zalecenia dotyczące zarządzania kluczami mogą się różnić w zależności od wersji. Skorzystaj z dokumentacji zainstalowanej wersji Ubuntu i aktualnych instrukcji wydawcy repozytorium.