Tired of ‘apt-get update’ failing with GPG errors like “NO_PUBKEY”? This guide from a senior DevOps engineer breaks down the root cause and provides three actionable fixes, from a quick patch to a permanent, scalable solution.

Great Marketing Tactics, Isn’t It? More Like a GPG Key Nightmare. Let’s Fix It.

I remember it like it was yesterday. It was 2 AM, and a P1 incident ticket lit up my phone. The on-call SRE was panicking. A critical hotfix for our main API couldn’t be deployed. The build pipeline was failing on every single one of our CI runners. The error? A cryptic message about a public key not being available: NO_PUBKEY. Some third-party monitoring tool we relied on had let their GPG key expire, and it brought our entire deployment process to a screeching halt. That night, fueled by stale coffee, I learned a lesson I’ll never forget: repository key management isn’t a minor detail; it’s a critical piece of infrastructure reliability.

So, What’s Actually Breaking?

Before we dive into the fixes, let’s understand the “why.” This isn’t just a random error. The Debian/Ubuntu package manager, apt, is built on a chain of trust. When you add a third-party repository (like for Docker, Node.js, or some monitoring agent), you’re also supposed to add its public GPG key to your system. Every time you run apt-get update, it checks the repository’s signature against that public key. This proves two things:

• Authenticity: The packages really are from who they say they are.
• Integrity: The packages haven’t been tampered with since they were signed.

When you see W: GPG error: ... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY [SOME_LONG_KEY_ID], apt is screaming at you: “I can’t verify the packages from this source! I don’t trust it!”

The Solutions: From Quick Fix to Proper Engineering

I’ve seen junior engineers get stuck here for hours. Let’s walk through the options you have, from the quick-and-dirty to the way we’d do it for our production fleet.

Solution 1: The “Get Me Out of Here” Quick Fix

This is the one you’ll find all over Stack Overflow. You’re on a single server, say dev-bastion-01, and you just need it to work right now. You can manually fetch the key and add it.

First, grab the missing key ID from the error message. Let’s say it’s A0E98406B222AAD6.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A0E98406B222AAD6
sudo apt-get update

Why it works: This command directly reaches out to a public keyserver, grabs the key associated with that ID, and adds it to the main `apt` keyring file. It’s fast and effective for a one-off problem.

Why I don’t love it: This approach is manual and doesn’t scale. It also adds the key to the global keyring (/etc/apt/trusted.gpg), which is now considered bad practice. If you’re managing more than one server, doing this everywhere is a recipe for configuration drift.

Solution 2: The “Do It Right” Permanent Fix (The Modern Way)

This is how we automate our server builds using tools like Ansible or Terraform. The old apt-key command is deprecated because managing a single global keyring is messy. The modern, accepted method is to store each repository’s key in its own file within the /etc/apt/trusted.gpg.d/ directory.

This is a two-step process. You get the key from the vendor (NEVER from a random keyserver for production systems) and place it correctly.

# Step 1: Download the official GPG key from the vendor's website.
# Always use a secure method like curl or wget.
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Step 2: Update your repository source file to USE that specific key.
# This is the critical part. You're telling apt exactly which key to use for this repo.
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Step 3: Now, the update will work perfectly.
sudo apt-get update

Why it’s better: This is clean, secure, and idempotent. Each repository has its own key, which is great for security and management. This is the method you should be using in your automation scripts. No more single point of failure in one big keyring file.

Solution 3: The “Break Glass in Case of Fire” Nuclear Option

I’m almost hesitant to write this down, but you need to know it exists so you can recognize and avoid it in production. You can tell apt to simply… not check the signature. You can mark a repository as trusted, effectively disabling the security check for it.

You would edit the repository’s file, like /etc/apt/sources.list.d/some-repo.list, and add [trusted=yes] to the line:

# BEFORE:
deb http://some.insecure.repo/ubuntu focal main

# AFTER:
deb [trusted=yes] http://some.insecure.repo/ubuntu focal main

Darian’s Warning: I cannot stress this enough. This is a massive security risk. You are telling your server to blindly trust and install any package from that source without verification. The only time this is even remotely acceptable is in a completely isolated, throwaway environment like a Docker container you’re building for a quick local test, and you have no other choice. Never, ever do this on a development, staging, or production server. You are inviting a man-in-the-middle attack.

Summary Table: Which Fix to Use?

So next time you see that NO_PUBKEY error, don’t just copy-paste the first command you find. Take a breath, understand what it’s telling you, and choose the right tool for the job. Your future self (at 2 AM, probably) will thank you for it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions