Apt Update Fails With NO_PUBKEY After Adding a VPN Repository

Your VPN vendor's apt source broke your package manager, and the fix is a decision rather than a command. NO_PUBKEY, or a complaint that the repository has no Release file, means apt declined to trust that source, so every later package operation keeps printing the same warning. The tunnel itself is probably innocent. Answer three questions about whether you still want that source, and the correct repair follows almost mechanically.

First, put the failure in the right bucket

A trust failure names the source file and either the missing key or the absent Release file. A transport failure looks different: TLS certificate errors, connection refused, timeouts, or a proxy refusing CONNECT. That distinction decides which article you are reading, because a VPN that intercepts TLS or blocks the vendor's host produces transport errors, not signature errors.

Run sudo apt update alone and read the tail, ignoring the cached hits above it. The line that matters names /etc/apt/sources.list.d/ and tells you which file to open.

If the failure follows the tunnel coming up, test with the tunnel down and with DNS resolved through the system resolver. A source that works without the VPN is a routing or interception question, and no amount of key management will fix it.

Three questions that pick the path

Do you still install or upgrade packages from this source? If the client is in active use, repair the trust. If you installed the client once and now import a plain profile into NetworkManager, the source is dead weight and removal is the honest fix.

Second, does the vendor publish a key and a fingerprint you can verify out of band? Third, who manages keys on this host: the distribution, or you? A source signed by a key you cannot verify is an update authority you should not grant.

Answering no to the first question ends the analysis. Answering yes to all three points at the signed-by repair, which is the only arrangement that both works and stays auditable. Mixing the two paths, by keeping the source and forcing it through, is the one option worth ruling out explicitly.

Why trusted=yes looks like a fix and is not

The sources.list manual page is direct about it. Setting the Trusted option to yes tells apt to accept the source even when it fails authentication, which switches off apt-secure for that repository. The page reserves it for a local context, if it is used at all.

That is not a narrower version of trusting the vendor. It removes the question of who signed the index, so anyone who can answer for that hostname can hand your machine packages that install as root.

Repair path: fetch the key, then pin it

Fetch the key from the location the vendor documents and dearmour it into an administrator-managed keyring, then point the repository line at that file so the trust cannot drift.

1. Read the failing line to get the key ID and the source filename.
2. Download the vendor's ASCII-armoured key and run gpg --dearmor into /etc/apt/keyrings/vendor-name.gpg.
3. Add [signed-by=/etc/apt/keyrings/vendor-name.gpg] to the entry in that vendor .list file.
4. Run sudo apt update and confirm the source fetches an index instead of repeating the signature warning.

Prefer /usr/share/keyrings for keys that arrive with a package and /etc/apt/keyrings for keys you place by hand. The split is not cosmetic: it tells the next administrator which keys will survive a package upgrade and which ones need a human.

Verify the fingerprint against the vendor's published value before you trust it. A key ID pasted from a forum post is how a machine ends up trusting an update authority nobody can name.

Removal path, and why the error can come back

Look at what the installer actually wrote, because several files can mention the same vendor and one of them is usually a leftover copy.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt reads only .list and .sources files from that directory, so a .save or .distUpgrade copy is already ignored; deleting it anyway stops a later reader from restoring it by accident. Removing the source does not uninstall anything, and apt may then describe the installed VPN package as locally installed or no longer available, which is a package-state message rather than the trust error returning.

The recurring case is older guidance that installed keys with apt-key into the global trusted ring. That path is deprecated, and a release upgrade can leave the key dropped or simply unconsulted, which is exactly why an error that was quiet for a year appears the week you upgrade. Check /etc/apt/trusted.gpg.d/, then move the trust decision into the repository line where it belongs. If the vendor still prints apt-key instructions, use signed-by anyway; it is the arrangement the manual documents, and it is the one that survives an upgrade.