How to fix GPG NO_PUBKEY Error: “The following signatures couldn’t be…”

You may occasionally encounter GPG errors during an apt-get update or apt-get upgrade when maintaining a Debian-based systems. These errors typically indicate that your system is missing one or more public keys required for verifying the integrity and authenticity of packages from its repositories.

This guide will walk you through resolving “NO_PUBKEY” errors, ensuring your system can securely update and install new packages. The instructions apply to the following errors and similar on all Debian-based systems, including Ubuntu:

Err:1 bionic InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY [KEY_ID]

An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: bionic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY [KEY_ID]

GPG error: trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY [KEY_ID]

GPG error: stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY [KEY_ID]

GPG Error: The following signatures couldn't be verified because the public key is not available: NO PUBKEY

Fixing NO_PUBKEY Errors

The “NO_PUBKEY” error occurs when the APT package manager cannot authenticate packages from a repository because it does not have the appropriate public keys. This lack of authentication keys prevents the system from ensuring that the packages are safe and intact, leading to potential security risks or system instability.

The error message typically looks something like this:

GPG error: ...The following signatures couldn't be verified because the public key is not available: NO_PUBKEY [KEY_ID]

Here, [KEY_ID] represents the missing public key’s ID. It’s crucial to address these errors to maintain the security and proper functioning of your system.

Step 1: Identify the Missing Key

Regardless of your system version, the first step in resolving a “NO_PUBKEY” error is identifying the missing key. The error message will specify the key ID that’s missing. Note this ID down as it is crucial for the upcoming steps to retrieve and trust the key.

Step 2: Retrieving and Storing the Key

Older versions of Ubuntu or Debian:

If you’re on newer versions of Ubuntu or Debian, then, skip to STEP 3 below.

Before Ubuntu 20.04/Debian 11, apt-key was used to manage keys for APT. If you’re using an older version of Ubuntu/Debian, these steps apply to you.

I’ve used strikethrough in the section below, to make sure you don’t accidentally cut and paste the old method into new versions of Ubuntu/Debian.

Retrieve the Key: Use the apt-key command to add the missing public key directly to the list of trusted keys:

sudo apt-key adv --keyserver --recv-keys [KEY_ID]

This command contacts a keyserver, requests the public key associated with [KEY_ID], and adds it to the trusted set.

Verify the Key Addition: Confirm that the key has been added to your list of trusted keys:

sudo apt-key list

Newer versions of Ubuntu or Debian:

Starting with Ubuntu 20.04 LTS and Debian 11, there has been a change in how APT handles public keys. The apt-key command is deprecated, in favor of a more secure and manageable approach involving direct keyring management.

Each repository’s keys are now recommended to be stored individually, either in the /etc/apt/trusted.gpg.d/ directory or specified in the repository’s source list entry, enhancing security and clarity.

Retrieve the Key: Use gpg to retrieve the public key from a keyserver:

sudo gpg --keyserver hkp:// --recv-keys [KEY_ID]

Export the Key to the Correct Directory: Export the key to a specific file within the /etc/apt/trusted.gpg.d/ directory or to a dedicated keyring file referenced in the repository source entry:

sudo gpg --export [KEY_ID] | sudo tee /etc/apt/trusted.gpg.d/[repository_name].gpg

Replace [repository_name] with a meaningful name for the repository the key belongs to. This command exports the key and writes it to a file that APT will use for verifying packages from the corresponding repository.

Configure APT to Use the New Key: After exporting the key to the correct directory, ensure your APT sources list or individual repository .list files in /etc/apt/sources.list.d/ refer to this keyring if necessary.

For most users, placing the key in /etc/apt/trusted.gpg.d/ should suffice without additional configuration.

Step 3: Update and Upgrade

With the new key in place run:

sudo apt update && sudo apt upgrade

By refreshing your package lists and upgrading, you apply all updates authenticated against the newly added key, ensuring your system’s integrity and security.

Troubleshooting and Best Practices for Key Management

Even with the correct approach, you might encounter issues or have concerns about key management. Here are troubleshooting tips and best practices to ensure a smooth experience with GPG keys and Ubuntu’s APT system.

Troubleshooting Tips

  1. Verbose Output for Errors
    If apt update is not working as expected, run it with verbose output to get more detailed information about what might be going wrong:sudo apt update -o Debug::Acquire::gpgv=true
  2. Check Key Availability and Expiry
    Keys might expire or become unavailable. Use gpg to check the key’s status and expiry date:
    gpg --list-keys [KEY_ID]
  3. Ensure Correct Permissions
    Ensure that the key files and directories have the correct permissions and are owned by the appropriate user (usually root):
    sudo chown root:root /etc/apt/trusted.gpg.d/[repository_name].gpg
    sudo chmod 644 /etc/apt/trusted.gpg.d/[repository_name].gpg
  4. Re-Add Key if Necessary
    If a key isn’t working correctly or if you suspect it’s corrupt, remove it and re-add it using the steps outlined in the previous parts.

Best Practices for Key Management

  1. Regularly Update Keys: Keep your keys updated. Occasionally, keys might be rotated for security reasons, or new keys might be issued by repositories. Stay informed about the repositories you use.
  2. Keep Your Keyring Clean: Remove old or unused keys to keep your keyring clean and manageable. This reduces the risk of trusting outdated or unnecessary keys.
  3. Understand What You’re Adding: Only add keys from trusted sources. Adding a key is an act of trust; ensure you know and trust the repository and the entity that issued the key.
  4. Use Official Sources: Always prefer official or well-trusted sources for your software. Unofficial or untrusted repositories can pose a significant security risk.

By following these troubleshooting steps and best practices, you can manage GPG keys more effectively and maintain the security and integrity of your system.

In managing your Ubuntu or Debian-based system, especially in dealing with APT and repository security, understanding and correctly handling GPG keys is essential.


Resolving “NO_PUBKEY” errors is a common task in system administration, reflecting the ongoing need to maintain a secure and trusted set of software sources.

This guide has provided you with both the traditional method and the updated method to add missing GPG keys and resolve the “NO_PUBKEY” errors.

Whether you’re running an older version of Ubuntu/Debian or the latest release, understanding how to manage GPG keys is a valuable skill that will help you ensure the smooth and secure operation of your system.

Stay informed about changes in package management and security practices, and your Linux systems will remain a reliable and secure platform for all your needs.

Tags: , , ,


  1. Out of curiosity, I tried the gpg --list-keys command and was surprised to get:

    gpg: directory '/home/pi/.gnupg' created
    gpg: keybox '/home/pi/.gnupg/pubring.kbx' created
    gpg: /home/pi/.gnupg/trustdb.gpg: trustdb created

    Should I be concerned?

  2. Good question. When you ran the gpg --list-keys command for the first time, GnuPG (GPG) initialized its environment because it was likely not used before on your system. There’s no need for concern.

Top ↑