リポジトリキーを修復してAPT署名エラーを修正する
セキュリティを無効にすることなく、問題の原因となっているソースを特定し、検証済みのキーを更新し、結果を確認することで、Ubuntu APT署名に関する警告を安全に解決します。
APT が「以下の署名を検証できませんでした」と報告した場合、同じ出力でリポジトリと特定のエラーコードを特定し、そのリポジトリの信頼できる署名キーまたはソースエントリを修復します。サードパーティのリポジトリの場合は、ソフトウェア発行元から現在のキーを取得し、そのソースにバインドしますSigned-By。署名チェックを無効にしたり、未知のキーをグローバルに追加したりしないでください。

アップデートを実行して、メッセージ全体を確認してください。
sudo apt update
の横にある URL と、 、 、 、 などのトークンを探してください。URLはErr:どのソースが失敗したかを示し、トークンは失敗の原因を絞り込みます。 APT はパッケージ インデックスを信頼する前に署名付きリポジトリのメタデータを検証するため、署名チェックの失敗は見た目の警告ではなくセキュリティ信号です。 Ubuntu のインストールには、デフォルトの Ubuntu アーカイブのキーが既に含まれているため、手動でキーを設定する必要があるのは、通常、後から追加したリポジトリのみです。NO_PUBKEYEXPKEYSIGKEYEXPIREDBADSIG
エラーメッセージに表示されているホスト名を検索して、ソース定義を見つけてください。例のホスト名を、ご自身のターミナルに表示されているホスト名に置き換えてください。

grep -R "packages.example.org" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
Ubuntu 24.04以降では、デフォルトで末尾が.deb822のソースファイルが使用されます.sources。古いインストールでは、多くの場合、1行の.listファイルが使用されます。リポジトリのURL、スイートまたはUbuntuコードネーム、および既存のSigned-Byエントリを確認してください。ソースがベンダーがサポートしなくなったリリースを指している場合は、Ubuntuリリースのベンダーの指示に従うか、そのソースを無効にしてください。キーでは、古くなった、または間違ったリポジトリパスを修正することはできません。
まずNO_PUBKEY、リポジトリが意図的にインストールしたものであることを確認してください。発行元の最新のインストール手順書を開き、署名キーのURLと完全なフィンガープリントをそのソースから取得してください。入手可能な場合は、フィンガープリントを別途公開されているベンダーのリファレンスと比較してください。短いIDがエラーと一致するからといって、無作為にキーサーバーからキーを取得しないでください。
ASCII アーマード.ascキーを公開しているベンダーの場合は、それを専用の APT キーリングとしてインストールしてください。例の URL を、その発行元が文書化している正確な URL に置き換えてください。
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://vendor.example/path/repo-signing-key.asc | sudo gpg --dearmor --yes -o /etc/apt/keyrings/vendor-archive.gpg
sudo chmod 0644 /etc/apt/keyrings/vendor-archive.gpg
ファイル.gpgは、APT の非特権ダウンロードユーザーが読み取り可能である必要があります。発行元がバイナリ.gpgキーリングを提供している場合は、再度デアーマー化するのではなく、その指示に従ってください。Ubuntu では、サードパーティのキーは別のキーリングに格納し、そのリポジトリから参照することで、キーを使用できるソースを制限することを推奨しています。

重複エントリを追加するのではなく、既存のソース定義を編集してください。 のような deb822 ファイルの場合は/etc/apt/sources.list.d/vendor.sources、ベンダーの実際の URI、スイート、コンポーネントの値を使用し、次にキーリング パスを追加します。
Types: deb
URIs: https://packages.example.org/ubuntu
Suites: YOUR_UBUNTU_CODENAME
Components: main
Signed-By: /etc/apt/keyrings/vendor-archive.gpg
既存のエントリが 1 行の.listファイルにある場合、同等の構文は ですdeb [signed-by=/etc/apt/keyrings/vendor-archive.gpg] https://packages.example.org/ubuntu YOUR_UBUNTU_CODENAME main。リポジトリのドキュメント化されたスイートとコンポーネントを保持します。例の値はプレースホルダーです。apt-key addは使用しないでください。非推奨であり、グローバルな信頼済みキーは、サードパーティのキーに意図したよりも広い権限を与える可能性があります。
メッセージに「」EXPKEYSIGまたは「」と表示された場合KEYEXPIRED、署名キーの有効期限が切れているか、ベンダーがキーを更新した可能性があります。ベンダーの最新の手順に従って代替キーをダウンロードして検証し、ソースのキーリングを更新してください。有効期限を無視して古いキーの信頼性を延長しないでください。
リポジトリが公式のUbuntuアーカイブである場合は、サードパーティのキーをインポートしないでください。システムクロックが正しいことを確認しtimedatectl status、ソースが有効なUbuntuアーカイブURLとインストール済みのリリースのコードネームを使用していることを確認してください。ubuntu-keyringパッケージにはUbuntuアーカイブ署名キーが含まれています。パッケージ管理が信頼できるUbuntuソース経由でまだ機能している場合は、次のコマンドでパッケージを更新してください。
sudo apt install --reinstall ubuntu-keyring
このBADSIGメッセージは、署名がAPTが受信したメタデータと一致しなかったことを意味します。キーのインポートを繰り返すのは、通常、適切な対応ではありません。システムクロックの誤り、ミラーの古さや不整合、キャッシュプロキシ、またはリポジトリ側の公開の問題がないか確認し、原因を修正してから再試行してください。サードパーティソースのみが失敗し、それが不要な場合は、そのソースのメンテナーに連絡している間、そのソース固有の.sourcesエントリを無効にしてください.list。セキュリティ検証は有効にしておいてください。

再度実行してくださいsudo apt update。影響を受けるリポジトリが署名警告なしで取得され、APT が に到達したら、修復は完了ですReading package lists... Done。更新が成功したからといって、サードパーティの発行者が安全であると保証されるわけではありません。メタデータ署名が、信頼することを選択したキーと一致することを確認するだけです。検証がまだ失敗する場合は、リポジトリの URL、コード名、キーのフィンガープリント、キーリングの権限、および正確なエラー トークンを再確認してから、別の変更を行ってください。
サポートされているソースおよびキーの形式については、Ubuntu のサードパーティリポジトリに関するガイダンス、Ubuntu apt-secure マニュアル、およびUbuntu アーカイブの整合性に関するドキュメントを参照してください。
セキュリティを無効にすることなく、問題の原因となっているソースを特定し、検証済みのキーを更新し、結果を確認することで、Ubuntu APT署名に関する警告を安全に解決します。
平衡三相公式を学び、線間電圧、電流、kW、kVA、力率を段階的に変換する方法を、計算例と確認すべき限界値とともに解説します。
CPUQuotaとMemoryMaxを設定したsystemdスコープ内でワークロードを実行し、その後cgroup v2を通じて制限を確認します。
Ubuntu 24.04 上で、ローカルホスト専用のリスナー、リゾルバの選択、および DNS 切り替え前のチェック機能を備えた dnscrypt-proxy を Pi-hole のローカル DoH ブリッジとして設定します。
アプリやハードウェアのトラブルシューティングを行う前に、Ubuntuのタッチパッド設定を確認し、Waylandが有効になっていることを確認し、GNOMEに組み込まれているスワイプ操作をテストしてください。
2台のディスクで構成されるDebian 12 RAID 1データアレイを作成および検証し、安全にフォーマットした後、再起動後にアセンブルおよびマウントされるように構成します。
既存の Debian 12 スワップパーティションにランダムキー暗号化を設定し、アクティブな dm-crypt マッピングを確認し、ハイバネーションのトレードオフを理解する。
Ubuntu 24.04 の SSH アカウントを、chroot、適切なパーミッション、マッチルール、および安全なテストを使用して、指定された SFTP フォルダーに制限し、シェルアクセスを許可しないようにします。
Ubuntuのdpkgフロントエンドロックを所有しているプロセスを特定し、パッケージの処理を完了させ、ロックファイルを削除せずに中断されたインストールを修復します。
Timeshiftを使用してUbuntu Desktop上でBtrfsシステムの定期的なスナップショットを設定し、Ubuntuのサブボリュームレイアウトを確認し、保持期間を選択し、スナップショットで保護できないものを理解する。