Fix the NO_PUBKEY GPG Error on apt update

You run sudo apt update, and one repository fails with a GPG error ending in NO_PUBKEY followed by a long hexadecimal key ID. APT can still update the other repositories, but it rejects the new package index from the affected source and may continue using an older cached copy.

This usually happens after you add a third-party repository, or when its owner rotates the signing key. This guide explains how to identify the affected repository, install its verified key under /etc/apt/keyrings, and limit that key to the correct source with signed-by.

Quick Reference #

For a printable quick reference, see the APT cheatsheet .

What the NO_PUBKEY Error Means #

A typical failure looks like this:

Err:7 https://repo.example.com/apt stable InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
Reading package lists... Done
W: GPG error: https://repo.example.com/apt stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0123456789ABCDEF
E: The repository 'https://repo.example.com/apt stable InRelease' is not signed.

APT checks the signature on a repository’s InRelease file before it trusts the package index. When the matching public key is missing, unreadable, or no longer current, APT cannot confirm that the metadata came from the repository owner.

The URL identifies the affected repository. The value after NO_PUBKEY, here 0123456789ABCDEF, is the ID of the key that signed the metadata. You can use that ID to inspect a candidate key, but you should verify the key’s full fingerprint against the repository owner’s documentation before trusting it.

Import the Key From the Repository Owner #

The preferred fix is to download the key from the same organization that operates the repository. Do not substitute a key URL from an unrelated tutorial, even when the key ID looks correct.

First, create the directory for locally managed APT keyrings:

sudo install -m 0755 -d /etc/apt/keyrings

Find the current signing-key URL and fingerprint in the repository’s official installation documentation. If the provider publishes an ASCII-armored key, download it and convert it to a binary OpenPGP keyring. Replace the example URL and filename with the provider’s values:

curl -fsSL https://repo.example.com/apt/gpg.key |
  gpg --dearmor |
  sudo tee /etc/apt/keyrings/example.gpg > /dev/null
sudo chmod 0644 /etc/apt/keyrings/example.gpg

The curl -f option makes the command fail when the server returns an HTTP error instead of quietly passing an error page to GnuPG. The final chmod ensures that the _apt system user can read the keyring.

Some providers publish a ready-to-use binary .gpg keyring. In that case, download it directly without gpg --dearmor. A provider may also use an ASCII-armored .asc file, which modern APT versions can reference directly. Keep the filename extension consistent with the key format.

Before you connect the key to the repository, display its full fingerprint:

gpg --show-keys --with-fingerprint --with-subkey-fingerprint /etc/apt/keyrings/example.gpg

Compare the primary fingerprint with the one in the provider’s documentation. The 16-character value from the APT error is a key ID, so it should match the last 16 characters of the primary fingerprint or of one of its signing subkeys. Stop if the documented fingerprint and downloaded key do not match.

Point the Repository to the Keyring #

The key does not become active merely because it exists under /etc/apt/keyrings. The affected repository entry must reference it with signed-by.

Use the host from the error message to find the source file. Replace repo.example.com with the actual repository host:

grep -R -n --include='*.list' --include='*.sources' \
  'repo.example.com' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

For a traditional .list file, add signed-by inside the option brackets. If the entry has no brackets, add them between deb and the URL:

deb [signed-by=/etc/apt/keyrings/example.gpg] https://repo.example.com/apt stable main

If the entry already has an option such as arch=amd64, keep both options in the same brackets:

deb [arch=amd64 signed-by=/etc/apt/keyrings/example.gpg] https://repo.example.com/apt stable main

For the newer DEB822 format, add the Signed-By field to the existing .sources stanza:

Types: deb
URIs: https://repo.example.com/apt
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/example.gpg

Preserve the repository’s existing URI, suite, components, and architecture settings. Only add or correct the keyring reference.

Run the update again after saving the source file:

sudo apt update

The NO_PUBKEY error for that repository should no longer appear.

Fetch a Key From a Keyserver #

Use a public keyserver only when the repository owner publishes the full fingerprint but does not provide a downloadable key. A keyserver can return a key for an ID, but it does not prove that the key belongs to the repository.

Create an isolated temporary GnuPG home, then fetch the ID shown in the error. Replace the example ID with your missing key ID:

key_tmp=$(mktemp -d)
gpg --homedir "$key_tmp" \
  --keyserver hkps://keyserver.ubuntu.com \
  --recv-keys 0123456789ABCDEF

Display the complete fingerprint before exporting anything:

gpg --homedir "$key_tmp" --fingerprint --with-subkey-fingerprint \
  0123456789ABCDEF

Compare it with the fingerprint published by the repository owner. If it matches, export the key in the binary OpenPGP format that APT expects:

gpg --homedir "$key_tmp" \
  --export-options export-minimal \
  --export 0123456789ABCDEF |
  sudo tee /etc/apt/keyrings/example.gpg > /dev/null
sudo chmod 0644 /etc/apt/keyrings/example.gpg
rm -rf "$key_tmp"

Add the keyring to the repository’s signed-by or Signed-By setting as shown in the previous section, then run sudo apt update.

If the key is already in your personal GnuPG keyring, run gpg as your own user so that it reads that keyring, and keep sudo on the tee command that writes the file:

gpg --export-options export-minimal --export 0123456789ABCDEF |
  sudo tee /etc/apt/keyrings/example.gpg > /dev/null
sudo chmod 0644 /etc/apt/keyrings/example.gpg

Fix Keys for Official Ubuntu or Debian Repositories #

A default Ubuntu or Debian installation already includes the keys for its official repositories. If the failing URL belongs to Ubuntu or Debian, do not replace the archive key with one copied from a third-party page.

On Ubuntu, reinstall the package that provides the Ubuntu archive keys:

sudo apt install --reinstall ubuntu-keyring

On Debian, reinstall the Debian archive key package:

sudo apt install --reinstall debian-archive-keyring

Then retry the update:

sudo apt update

If the error remains, check that your source entries use the correct release codename and that the installed release still receives updates. An unsupported release or a repository entry copied from another distribution needs a source correction, not an extra trusted key.

Troubleshooting #

The same NO_PUBKEY error appears after importing the key
Check the signed-by or Signed-By path in the affected source file. It must exactly match the keyring filename. Confirm that the file is readable with ls -l /etc/apt/keyrings/NAME.gpg, then set safe permissions with sudo chmod 0644 /etc/apt/keyrings/NAME.gpg. If the path and permissions are correct, compare the fingerprint again because the repository may have rotated its signing key.

APT warns that the key is stored in the legacy trusted.gpg keyring
Debian 12 and Ubuntu 24.04 still fall back to the single /etc/apt/trusted.gpg file and print Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details. APT 3.0, which ships in Debian 13 and Ubuntu 25.04, dropped that fallback, so a repository whose key lives only in that file starts failing with NO_PUBKEY after the upgrade. Export the key into its own keyring, then point the source at it with signed-by:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg \
  --export 0123456789ABCDEF |
  sudo tee /etc/apt/keyrings/example.gpg > /dev/null
sudo chmod 0644 /etc/apt/keyrings/example.gpg

gpg reports no valid OpenPGP data
The key URL may be wrong, or the server may have returned an HTML error page. Open the repository owner’s current installation instructions and copy the key URL again. Keep curl -f in the download command so an HTTP error stops the pipeline.

gpg reports keyserver receive failed
The keyserver may be blocked or temporarily unavailable. The hkps://keyserver.ubuntu.com address uses HTTPS, which normally works through networks that block the traditional HKP port. Prefer the repository owner’s direct key URL whenever one is available.

gpg or curl is not installed
Install the required packages from the enabled Ubuntu or Debian repositories, then retry the key download:

sudo apt install curl gnupg ca-certificates

APT reports conflicting values for Signed-By
The same repository is defined more than once with different keyring paths. Search /etc/apt/sources.list.d/ for the repository host, compare the matching .list and .sources files, and remove or disable the stale duplicate entry.

Several repositories report NO_PUBKEY
Handle each affected repository separately and verify every key against its owner. Repositories from the same provider may use one signing key, but unrelated repositories should not share a keyring merely because the errors appeared at the same time.

Conclusion #

A NO_PUBKEY error should lead you back to the repository owner, not to an unverified key command. Once the full fingerprint matches, store the key under /etc/apt/keyrings and limit it with signed-by; for more on source configuration, see adding an APT repository on Ubuntu and the apt command guide .

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page