How to Solve The Following Signatures Couldn't be Verified Because the Public Key is Not Available: NO_PUBKEY EB3E94ADBE1229CF

The error NO_PUBKEY EB3E94ADBE1229CF occurs when your Linux package manager cannot verify software signatures because the corresponding public key is missing from your system. To resolve this, you must import the specific GPG key into your trusted keyring using modern command-line tools, ensuring that future updates are authenticated correctly without relying on deprecated methods.

Understanding the Error Context

When you run commands like apt update or apt upgrade on Ubuntu or Debian-based systems, the package manager checks the digital signatures of repositories to ensure integrity and authenticity. The message indicates that a repository has been added, but the signing key for that repository is not present in your local trust store. This is a security feature designed to prevent tampering with software sources. The specific key identifier EB3E94ADBE1229CF is associated with a particular software source. While the exact source can vary depending on your system configuration, it often relates to third-party repositories such as those for database servers (like MySQL or MariaDB), development tools, or enterprise-grade applications. Without this key, your system refuses to install or update packages from that source, citing the inability to verify the signature. Ignoring this warning can expose your server to potential security risks, so it is critical to address it properly. For more information on maintaining a secure environment, see our guide on Securing an Ubuntu Server for Development Purposes.

Why Deprecated Methods Fail

Historically, users resolved this issue by using the apt-key command. However, this method has been deprecated in recent versions of Ubuntu (specifically 20.04 LTS and later) and Debian. The apt-key tool managed keys globally, which created security vulnerabilities where any repository could potentially add malicious keys to the global trust store. Modern Linux distributions enforce strict separation of keys per repository to enhance security. Continuing to use apt-key adv --keyserver ... --recv-keys ... may still work temporarily, but it generates warnings and will eventually stop functioning entirely. Furthermore, keys added via apt-key are not automatically cleaned up when repositories are removed, leading to clutter and potential confusion during audits. Therefore, adopting the modern approach using /etc/apt/trusted.gpg.d/ or /usr/share/keyrings/ is essential for long-term system stability and compliance with current security standards.

Step-by-Step Solution: Importing the Key

To fix the NO_PUBKEY error permanently and securely, follow these steps to download and install the public key manually. This method ensures the key is stored in a location specifically designated for trusted repositories.

1. Identify the Source: First, determine which repository is causing the issue. Check your output logs or review files in /etc/apt/sources.list and /etc/apt/sources.list.d/ to find the URL associated with the missing key.
2. Create a Directory for Keys: If it does not already exist, create a directory to hold the keyring file. Run the following command to create a dedicated folder for trusted keys:

sudo mkdir -p /etc/apt/trusted.gpg.d

3. Download the Public Key: Use wget or curl to fetch the key from the official keyserver. Replace the key ID with the one specified in your error. For example:

sudo wget -qO - https://keyserver.ubuntu.com/pks/lookup?op=get\&search=0xEB3E94ADBE1229CF | sudo tee /usr/share/keyrings/EB3E94ADBE1229CF.gpg > /dev/null

Note: Some repositories provide their own key servers. It is always best practice to download keys directly from the vendor’s website if available, rather than a generic keyserver, to ensure authenticity.

4. Update APT Sources Configuration: You must now tell your apt sources to use this new keyring. Open the relevant .list file in /etc/apt/sources.list.d/ and modify the line to include the [signed-by=...] option. For example:

deb [signed-by=/usr/share/keyrings/EB3E94ADBE1229CF.gpg] http://example.com/repo stable main

If you do not have a specific list file yet, you can also place the key in /etc/apt/trusted.gpg.d/ and it will be trusted globally, though the per-repository method above is preferred for security granularity.

5. Verify the Fix: Run sudo apt update again. The error should no longer appear, and the package lists should download successfully.

Alternative: Using GPG Directly

If the wget method fails due to network restrictions or certificate issues, you can use gpg directly. This approach gives you more control over the key retrieval process.

gpg --no-default-keyring --keyring gnupg-ring:/tmp/temp-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EB3E94ADBE1229CF
chmod 644 /tmp/temp-keyring.gpg
sudo cp /tmp/temp-keyring.gpg /usr/share/keyrings/EB3E94ADBE1229CF.gpg
rm /tmp/temp-keyring.gpg

This sequence creates a temporary keyring, imports the key, converts permissions, moves it to the permanent location, and cleans up the temporary file. This is particularly useful for automated scripts or environments where wget might behave unpredictably. Understanding how your system handles these cryptographic operations is part of broader kernel and system management practices, similar to topics discussed in Understanding the sysctl fs.quota.syncs Parameter in Linux and Ubuntu Kernel.

Preventing Future Issues

To avoid encountering this error repeatedly, consider automating key management. Many modern software providers offer installation scripts that handle key downloading and source configuration automatically. Always prefer these official scripts over manual copy-pasting of commands. Additionally, regularly audit your installed keys using ls -l /etc/apt/trusted.gpg.d/ and ls -l /usr/share/keyrings/ to remove obsolete keys from repositories you no longer use. This keeps your system lean and reduces the attack surface. For deeper insights into managing server configurations, including network interfaces that might affect keyserver connectivity, refer to How do Ubuntu-server network interfaces work?.

Frequently Asked Questions

What happens if I ignore the NO_PUBKEY error?

You will be unable to install or update packages from the affected repository. Your system will flag these packages as unverified, which can break dependency chains for other software that relies on them. This effectively locks you out of receiving security patches for that specific software source.

Can I use apt-key to fix this error quickly?

While apt-key might temporarily silence the error, it is deprecated and generates warnings. On Ubuntu 20.04 and newer, it may fail entirely or cause future compatibility issues. It is strongly recommended to use the /usr/share/keyrings/ method instead for long-term stability.

How do I know which keyserver to use?

The most common keyserver is keyserver.ubuntu.com. However, some vendors like Microsoft, Google, or Docker use their own specific keyservers. Always check the official documentation of the repository provider to see which keyserver they recommend for downloading their public keys.

Is it safe to import keys from random websites?

No, you should only import keys from official sources provided by the software vendor or trusted key servers like Ubuntu’s. Importing keys from unknown sites can compromise your system security by allowing unverified software to be installed. Always verify the fingerprint of the key against the vendor’s official announcement.

Why does my apt update still fail after importing the key?

This usually means your /etc/apt/sources.list.d/ file is not configured to point to the new keyring. You must add the [signed-by=/path/to/key.gpg] clause to the deb line in your source list file. Without this link, apt does not know which key to use for verifying that specific repository.