UbuntuでGPGエラー「以下の署名を検証できませんでした」を修正する方法

まず、警告が発生したリポジトリを特定し、そのリポジトリのキーまたは設定を修正してください。APT の署名チェックは無効にしないでください。「次の署名を検証できませんでした」というメッセージは、APT がリポジトリのメタデータが信頼できるキーで署名されていることを確認できないことを意味します。署名が検証されるまで、APT はそのソースの使用を拒否する可能性があります。ランダムなキーを追加したり、ソースを信頼済みに設定したりすると、警告は非表示になりますが、本来提供されるはずの保護機能が失われます。

例えば、 Ubuntu自身のアーカイブラインは正常に更新されるのに、ブラウザベンダーのリポジトリに関するsudo apt updateレポートが不足しているとしますNO_PUBKEY。この場合、そのベンダーが現在公開している署名キーをインストールし、そのリポジトリにスコープを設定するのが適切な解決策です。Ubuntuのアーカイブキーリングを再インストールしても、サードパーティキーの問題は解決しません。以下のコマンドはテンプレートです。サンプルリポジトリの詳細は、ソフトウェア発行元の公式指示に従って値を変更してください。

キーを変更する前に、正確なエラーメッセージを確認してください。

更新コマンドを実行し、リポジトリのURLとエラーコードが同じ出力行に表示されることをメモしてください。

sudo apt update

APTは通常、ソースをURLとリリーススイート（例：nobleまたは）で識別しますjammy。複数のソースが設定されている場合、複数のエラーが表示されることがあります。変更を加える前に、各メッセージをそれぞれのリポジトリと照合してください。これらの一般的なシグネチャは、それぞれ異なる原因を示しています。

エラーメッセージに時刻に関する記述がある場合は、まずシステムクロックを確認してください。

署名とリポジトリのメタデータには有効期間があります。古いスナップショットから復元されたサーバー、デュアルブート構成のコンピューター、または時刻サービスに障害が発生したマシンでは、時計の時刻が大きくずれているため、現在のメタデータが無効に見える場合があります。システム時刻を確認してください。

timedatectl status

表示されている日付と時刻が正確であり、時刻同期が有効になっていることを確認してください。時計が間違っている場合は、ホストの時刻サービスを修正するか、設定されているネットワーク時刻同期方法を有効にしてから、再試行してsudo apt updateください。おおよその日付を手動で設定することは避けてください。時計は実際の時刻を反映する必要があります。時刻修正では、リポジトリキーの欠落または期限切れは修復されないため、メッセージがエラーNO_PUBKEYのままの場合はEXPKEYSIG、関連するキーの手順を続行してください。

サードパーティリポジトリキーの欠落または期限切れを修正します

Ubuntu の現在のガイダンスでは、サードパーティのキーを専用のキーリングに保存し、一致するソースからそのキーを参照することを推奨していますSigned-By。これにより、どのキーでリポジトリを認証できるかが制限されます。Ubuntu はこのアプローチをサードパーティ リポジトリ ガイドで説明しており、APT はsources.list マニュアル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ファイルが使用されます.sources。それ以前のリリースでは、一般的に末尾が の1行ファイルが使用されます.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. リポジトリソースでキーのスコープを設定する

1行で.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エントリを使用することで、信頼関係が明確になり、1 つのレポジトリキーを信頼することによる影響を軽減できます。

警告がUbuntu自身のアーカイブに関するものである場合

まず、リポジトリスイートがインストールされている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、、、または類似のオプションを恒久的な解決策として使用しないでください。APT の署名チェックはallow-insecure=yes、リポジトリのメタデータが、信頼するように選択したキーで署名されていることを検証します。これを無効にすると、APT はその整合性チェックを提供できなくなります。APT のセキュア マニュアルには、アーカイブ認証チェーンとその制限について説明されています。発行者がリポジトリを撤回した場合、メタデータの署名を停止した場合、または検証可能なキー フィンガープリントを提供しない場合は、検証をバイパスするのではなく、そのソースを削除または無効にしてください。--allow-unauthenticated

ドキュメントは2026年10月6日に確認済みです。Ubuntuのリポジトリ形式とキー管理に関する推奨事項はリリースによって異なる場合があります。インストールされているUbuntuバージョンのドキュメントとリポジトリ発行元の最新の指示に従ってください。