Kali "apt-key: Command Not Found": The Modern Way to Add a Repository Key
If sudo apt-key throws "command not found," the tool isn't broken — it's gone. On current Kali, apt-key has been fully removed from the base install, not just deprecated, so the fix isn't "reinstall it," it's "stop using it": import the key into a keyring file and point your source at it with Signed-By instead.
Jake had this exact line staring at him on a customer's laptop last week: sudo: apt-key: command not found. He'd pulled up an old forum post that told him to run apt-key adv --keyserver ... --recv-keys, and the terminal just laughed at him. Twenty minutes of his Saturday gone, and the machine still couldn't apt update.
🙋♂️ Jake's Reality Check
"I've used apt-key on every Kali box I've ever touched. Why would they just delete a command people rely on?"
Because the old design was a security problem, not a convenience feature. Every key you added with apt-key landed in one shared file, and apt trusted every key in that file for every repository on the system — not just the one you added it for. Removing the command forces you onto a system where each repository is only trusted by the key you scoped to it.
Why apt-key says "command not found" and not just "deprecated"
Most of what's written online about apt-key still describes the old middle stage: a warning, not a missing command. You'd run apt-key add, it would still work, and it would print "Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead." That was the situation for years, starting with Debian 11.
That's not what's happening if your terminal says command not found. That message means the apt-key program itself is not on the disk to run — the package that provides it was dropped from the base install. Kali tracks Debian's Testing branch rolling forward, so changes that land in Debian's next stable release reach Kali well before most people are running that release themselves. apt-key's removal is one of those changes.
🕐 What changed between versions
- Before (Debian 10 and earlier, older Kali):
apt-keywas the normal way to trust a repository's signing key, and it worked without complaint. - Middle stage (Debian 11 / early Kali rolling snapshots):
apt-keystill ran, but printed the deprecation warning on every use. - Now: the package providing
apt-keywas removed entirely for Debian 13 "Trixie," and Kali — tracking Testing — carries that removal, which is why current Kali installs get "command not found" instead of a warning. - What that means for you: any install guide, forum answer, or old blog post (including some of ours) that tells you to run
apt-key addorapt-key advis describing a command your system no longer has.
Which error do you actually have?
"Apt-key trouble" covers three genuinely different symptoms, and the fix is not the same for all three. Before you copy any command, match your error to a row here.
| What you see | What it means | Where to go |
|---|---|---|
sudo: apt-key: command not found |
The apt-key program isn't installed. You're on current Kali and something (a guide, a script) tried to use it anyway. | Modern method, below |
Warning: apt-key is deprecated... |
apt-key still ran, on an older or interim system, but you should switch off it before it disappears from your box too. | Modern method, below |
NO_PUBKEY 827C8569... or sqv errors on apt update |
This is a missing or expired key for a repository you already have configured, most often Kali's own archive. | Kali's own key, below |
If you landed here typing "apt command not found" rather than "apt-key command not found," that's a different, much simpler problem — it means the apt package manager itself isn't on your PATH, which on Kali almost always means you're inside a minimal container or chroot that skipped installing the base system. Run which apt and echo $PATH first; if apt genuinely isn't present, that image needs apt-get install --reinstall apt from whatever base tool built it, not a key fix.
The modern way to add any repository key
Every apt-key command you've ever run did two things at once: it fetched a key, and it dropped it into a single shared trust file. The replacement splits those two steps apart on purpose.
| Method | Status on current Kali | Use it when |
|---|---|---|
apt-key add |
Command not found. Fully removed. | Never — every guide using this is out of date for your system. |
Dropping a key straight into /etc/apt/trusted.gpg.d/ |
Still works, but still globally trusted. | Emergency only — it works, but recreates the exact problem apt-key had. |
gpg --dearmor into a keyring file + Signed-By |
The current, supported method. | Every time — for Kali's own repo and for third-party vendor repos. |
Here's the generic recipe. It works whether the key belongs to Kali's own archive or a vendor's third-party repository — only the URL and the filename change.
- Make a folder for keys, if you don't already have one.
sudo mkdir -p /etc/apt/keyrings— this directory has been the recommended home for manually-managed keys since apt version 2.4, which every current Kali install has. - Download the key and convert it to binary in one step.
curl -fsSL https://example.com/key.asc | sudo gpg --dearmor -o /etc/apt/keyrings/vendorname.gpg—gpg --dearmoris the piece that used to happen silently inside apt-key. It turns the human-readable ASCII key into the binary format apt actually reads. - Point the repository entry at that exact file with
Signed-By, either as a bracket option on a one-line source (deb [signed-by=/etc/apt/keyrings/vendorname.gpg] https://example.com/apt stable main) or as aSigned-By:line in a deb822-style.sourcesfile — see the DEB822 section below for that format. - Refresh and confirm.
sudo apt update— if the repository's line no longer prints a signature warning, the key is correctly scoped.
Fixing Kali's own missing archive key specifically
If the actual symptom is apt update failing on Kali's own repository with NO_PUBKEY 827C8569F2518CC677FECA1AED65462EC8D5E4C5, that's not a "how do I use apt-key" question at all — it's that your system still has the old, now-superseded Kali signing key, or none at all. We covered the full background on why the key changed in a dedicated post; the short version here:
- Fetch the current Kali archive keyring directly:
sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpg - Confirm your repository entry references that exact path with
Signed-By— on a stock 2026.2 install it already does, inside/etc/apt/sources.list.d/kali.sources. - Run
sudo apt updateagain. The NO_PUBKEY line should be gone.
The current key's fingerprint is 827C 8569 F251 8CC6 77FE CA1A ED65 462E C8D5 E4C5 — worth checking that against what gpg --show-keys /usr/share/keyrings/kali-archive-keyring.gpg prints on your machine before you trust it.
- Fixing the Kali "missing key 827C8569..." apt update error
The full walkthrough for this exact NO_PUBKEY message, including what to do if the wget fails.
The DEB822 format, and why apt keeps mentioning it
Since Kali 2026.2, a fresh install no longer creates /etc/apt/sources.list at all. Instead the default repository lives in /etc/apt/sources.list.d/kali.sources, written in the newer "deb822" multi-line format instead of the old single-line one. It reads like this:
Types: deb
URIs: http://http.kali.org/kali/
Suites: kali-rolling
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/kali-archive-keyring.gpg
Notice the last line: Signed-By is built into the file format itself, rather than bolted on as a bracket option. That's the whole design goal — every repository entry now carries its own key reference, so there's no shared trust file for apt-key to manage in the first place.
If you're on an install that predates 2026.2, you're probably still running the old one-line sources.list — and that's fine; both formats work side by side. If you want to convert it yourself, apt ships a command for exactly that: sudo apt modernize-sources rewrites your one-line entries into deb822 .sources files and keeps the originals as .bak backups rather than deleting them. Run it once, then check the new files before your next apt update.
Adding a third-party (vendor) repository the modern way
This is the case Jake's customer actually had: a security tool's install page still said curl ... | sudo apt-key add -. Here's the same job done the current way, keeping the vendor's key scoped to only the vendor's repository.
- Get the vendor's key into a dedicated file.
curl -fsSL https://vendor.example.com/key.asc | sudo gpg --dearmor -o /etc/apt/keyrings/vendorname.gpg - Create a new file for the source — don't edit Kali's own.
sudo nano /etc/apt/sources.list.d/vendorname.sources, and write the deb822 block:Types: deb,URIs:the vendor's URL,Suites:andComponents:as their docs specify, andSigned-By: /etc/apt/keyrings/vendorname.gpg. - Leave
kali-rollingalone. Never point a vendor entry'sSuitesat an Ubuntu or Debian codename (likejammyorbookworm) even if that's what the vendor's copy-paste snippet says — mixing distributions into apt this way is how a routineapt full-upgradequietly breaks a Kali install. - Update and check for warnings.
sudo apt update; the vendor's line should refresh cleanly with no "NO_PUBKEY" or "not signed" text next to it.
✅ Why this is the one to use
A key scoped with Signed-By to one file can only vouch for that one repository. If a vendor's key were ever compromised, the blast radius is their repository alone — not every package source on the machine, which is what the old shared trusted.gpg file allowed.
Does this hit Ubuntu and Debian too, not just Kali?
Yes — this is a Debian-wide change, not a Kali quirk. Kali is built on Debian's Testing branch, so it simply gets the change earlier than stable Debian or Ubuntu LTS releases do. If you searched "ubuntu apt-key not found" or "sudo apt-key command not found" on a non-Kali box, the same underlying story applies: older Ubuntu and Debian stable releases still ship apt-key with the deprecation warning, and once they move onto a base tracking Debian 13 or later, the command disappears there too. The fix in every case is the same one described above — a keyring file plus Signed-By — regardless of which Debian-family distro you're on.
When the fix still fails: sqv errors and expired keys
⚠️ What this actually breaks
Current Kali doesn't verify repository signatures with plain gpg anymore — it uses a tool called sqv (part of the Sequoia-PGP project). If you see Sub-process /usr/bin/sqv returned an error code, that's not the same failure as a missing key. It usually means the key you have is present but has expired, or was signed in a format (SHA-1-based) that sqv now rejects outright.
Kali's own signing keys are periodically re-extended before they expire, so if you're hitting an sqv error on the Kali archive specifically, re-fetching the current keyring with the wget command in the Kali-key section above is usually the whole fix — you're pulling the freshly-extended key, not just a copy of the old one. For a third-party vendor key throwing the same error, check whether the vendor has published a newer key; there's no way to "renew" an expired key yourself, only to replace it with a current one from the source that issued it.
Why is any of this actually safer than the old apt-key file?
Ethan put it bluntly when Jake asked why this couldn't have just stayed simple: "The old system trusted everybody the same amount. A key you added for one weird packet-sniffing tool three years ago could sign a package for a repository it has nothing to do with, and apt would install it without blinking. That's not a hypothetical — it's exactly the shape of a supply-chain attack."
Jake pushed back: "Sure, but nobody's going to poison a random tool's repo just to get at my system." Ethan's answer was direct: "You don't need to be the target. You need to be running the same tool as the target, on a machine that trusts too many keys. Scoped trust means one bad key can only damage the one thing it was ever supposed to sign for."
That's the entire philosophy behind removing apt-key rather than just discouraging it: a tool that makes the secure behavior the default, rather than an opt-in extra step, is the tool that actually gets used correctly by people in a hurry — which, on a Saturday in Jake's shop, is everyone.
Automating this across more than one machine
If you're keeping several Kali VMs or lab machines in sync, wrap the key-fetch step in a tiny shell script rather than retyping it — a single file with the two commands (mkdir -p and the curl | gpg --dearmor pipeline) that you drop onto each machine and run once. Keep the vendor's .sources file itself in the same script or a config-management tool (Ansible, a simple rsync of /etc/apt/sources.list.d/) rather than hand-editing each box, so a key rotation on the vendor's side only means updating one script instead of remembering every machine you've ever touched.
If you landed here searching from Windows
If you searched "windows apt-get command not found," the honest answer is that this is expected, not a bug to fix: apt and apt-get are Debian-family Linux package managers, and Windows never ships them at the OS level. If you're seeing that message inside a WSL (Windows Subsystem for Linux) window running a Debian-based distribution, everything on this page applies to you exactly as written — you're inside a Linux environment. If you're seeing it in a plain Windows Command Prompt or PowerShell window with no Linux distro installed, that's Windows correctly telling you the command doesn't exist there; Windows has its own package managers (winget, or third-party tools like Chocolatey), and they're a separate topic from anything on this page.
Frequently asked questions
Why does apt-key say command not found instead of just a warning?
Because the package providing apt-key has been removed from current Kali entirely, not merely flagged as outdated. Older systems on the interim stage still see the deprecation warning because the program is still installed there; on current Kali, it isn't installed at all.
Is apt-key coming back?
No. Its removal tracks Debian's own roadmap, and Debian has been signaling this change since apt-key was first marked deprecated years ago. Plan around the keyring-plus-Signed-By method as the permanent replacement, not a temporary workaround.
Do I need to redo every repository I've ever added?
Only the ones you added with apt-key that are still active. Run apt update and watch for warnings mentioning "legacy trusted.gpg keyring" — those are the repositories still relying on the old shared trust file and worth migrating. A repository that's already updating cleanly doesn't need touching.
What is Signed-By and why does it matter?
Signed-By is an option on a repository entry that names the exact keyring file apt should use to verify that specific repository's packages. It replaces the old behavior of checking every package against every key on the system, scoping trust down to one key per repository instead.
Where should I put third-party keys, /etc/apt/keyrings or /usr/share/keyrings?
Either works technically, but the convention is to keep them separate: /usr/share/keyrings is where Kali and other packages store their own official keyrings, and /etc/apt/keyrings — recommended since apt 2.4 — is the intended home for keys you're managing yourself, like third-party vendor keys.
What does apt modernize-sources actually do?
It converts your existing one-line-style sources.list entries into the newer deb822 .sources format automatically, and saves the original files with a .bak extension rather than deleting them, so you can compare or revert if something looks off.
Is it safe to just delete /etc/apt/trusted.gpg?
Not without checking it first. That file may still hold keys that active repositories depend on. Run gpg --show-keys /etc/apt/trusted.gpg to see what's inside before removing anything, and migrate any keys you still need into scoped keyring files rather than deleting the source entirely.
I get NO_PUBKEY, not command not found — is this the same fix?
It's related but more specific. NO_PUBKEY means a particular repository's key is missing entirely, most commonly Kali's own archive key after a signing-key rotation. Use the dedicated Kali key fix above rather than the generic third-party recipe.
Why do I see sqv in the error instead of gpg?
Current Kali verifies repository signatures using sqv, a tool from the Sequoia-PGP project, rather than calling gpg directly. An sqv error usually points to an expired or improperly formatted key rather than a completely missing one.
Does this affect Ubuntu and Debian too, or just Kali?
It affects the whole Debian family. Kali sees it first because it tracks Debian's Testing branch, but Ubuntu and Debian stable releases will hit the same removal once they're built on a base that includes it.
Can I still use apt-key if I install gnupg separately?
Installing gnupg gives you the gpg command, but not apt-key itself — they're different packages, and apt-key was removed as its own package. Use gpg directly with the dearmor-and-Signed-By method described above instead of trying to resurrect apt-key.
What if the vendor's install page still tells me to use apt-key add?
Follow the intent, not the literal command: fetch the same key the vendor points you to, but pipe it through gpg --dearmor into a keyring file and reference it with Signed-By, rather than running the apt-key command their page shows.
Is DEB822 (.sources) required now?
Not required for existing installs — the older one-line sources.list format still works alongside it. Fresh Kali installs from 2026.2 onward default to DEB822, and apt is expected to eventually warn when it sees the old format, but nothing breaks by staying on the one-line style for now.
I'm getting this in Windows, not Linux — what does that mean?
If it's inside a WSL window running a Debian-based distro, treat it exactly like a Linux system and follow the steps above. If it's in plain Command Prompt or PowerShell with no Linux subsystem installed, apt was never available there — Windows uses its own tools like winget instead.
Will curl piped to gpg --dearmor break anything if I run it twice?
No — running it again simply overwrites the destination keyring file with the same key data, since the -o flag replaces the file rather than appending to it. It's safe to re-run if you're unsure whether the first attempt succeeded.
How do I check which repos on my system are still using the deprecated trusted.gpg keyring?
Run apt update and read the output carefully — entries still relying on the shared file print a line mentioning "legacy trusted.gpg keyring" or "see the DEPRECATION section in apt-key(8)." Those are the ones worth migrating to a scoped Signed-By keyring.
Revision note. Written September 2026, covering current Kali rolling (2026.2) and its Debian Testing-tracked removal of apt-key, alongside the equivalent situation on Ubuntu and Debian stable releases still carrying the older deprecation warning. This will need a fresh look once mainline Debian stable itself drops apt-key and the "command not found" version of this problem becomes the universal one rather than the Kali-first one. If you're staring at a broken apt update right now, take a breath — it's a five-minute fix, not a reinstall.If you found it was nto working, please let me know through contact us page or comments. I will update the post accordingly! thanks!