The command
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys often fails due to deprecated GnuPG versions, network restrictions blocking port 80, or invalid key identifiers. Modern Ubuntu and Debian systems have moved away from the global
apt-key store in favor of repository-specific signing keys located in
/etc/apt/trusted.gpg.d/. This shift requires a different approach to managing package authentication, rendering the legacy command obsolete on newer releases.
Understanding Why the Command Fails
The primary reason this command stops working is that
apt-key has been deprecated since Ubuntu 21.10 and Debian 11. The developers removed it because storing all trusted keys in a single global pool was a security risk. If you are running a recent version of Linux, attempting to use this command will likely result in an error message stating that the method is not supported or that the command is no longer available.
Even on older systems where the command exists, it frequently fails for other reasons. Network issues can prevent connection to the Ubuntu keyserver, especially if your firewall blocks HTTP traffic on port 80. Additionally, users often mistype the long hexadecimal key ID. A valid key ID for these operations is typically 40 characters long, though shorter IDs may work if they are unique within the keyring. If you copy the key ID incorrectly, the keyserver cannot locate the specific public key you need.
Modern Alternative: Using Repository-Specific Keys
The correct modern approach involves downloading the specific signing key for the repository you are trying to add and placing it directly into the
/etc/apt/trusted.gpg.d/ directory. This isolates the trust relationship to that specific source rather than granting global trust to a single key.
First, identify the repository URL and the associated signing key. Most official Ubuntu repositories provide a script or a direct link to their GPG key. For example, to add a third-party repository, you should look for documentation that specifies how to import its key. Instead of using
apt-key, you use
curl or
wget to download the key file.
Here is the standard procedure for adding a new repository securely:
- Download the Key: Use
curl to fetch the public key from the provider's website. Save it as a .gpg or .asc file.
- Move the Key: Move the downloaded file to
/etc/apt/trusted.gpg.d/. This location is automatically scanned by apt during updates.
- Add the Source List: Add the repository line to
/etc/apt/sources.list or a new file in /etc/apt/sources.list.d/.
- Update Package Lists: Run
sudo apt update to verify that the system can now authenticate packages from the new source.
This method ensures that if a key is compromised, it only affects the specific repository that uses it, not your entire system. It also aligns with current best practices for system security and maintainability.
Troubleshooting Network and DNS Issues
If you are still on an older system or must use a custom keyserver, network connectivity is the next most common failure point. The default keyserver uses HTTP, which can be blocked by corporate firewalls or restrictive network policies. You can test connectivity by pinging
keyserver.ubuntu.com or checking if port 80 is open.
If you suspect a DNS resolution issue, try flushing your local DNS cache or switching to a public DNS resolver like Google's
8.8.8.8 or Cloudflare's
1.1.1.1. Sometimes, the keyserver itself may be temporarily unavailable or under maintenance. In such cases, waiting a few minutes and retrying the command may resolve the issue without further intervention.
For more complex networking problems, consider using HTTPS instead of HTTP if the keyserver supports it, although the standard Ubuntu keyserver primarily relies on HTTP. You can also try alternative keyservers such as
hkps://keys.openpgp.org if you are dealing with user-generated keys rather than official distribution keys.
Handling Deprecated Key Formats
In some cases, the key format itself may be incompatible with your current GnuPG version. Older keys might use algorithms that are considered weak by modern standards. When this happens,
apt-key may refuse to import them entirely. The solution is to request a new version of the key from the repository maintainer that uses stronger cryptographic algorithms.
If you encounter errors related to parsing the key file, ensure that the file is not corrupted. You can verify the integrity of the downloaded key by comparing its checksum against the value provided by the source. This step is crucial when dealing with sensitive infrastructure components.
For related troubleshooting on package management errors, you might find it helpful to read about resolving
E: Unable to parse package file /var/lib/apt/extended_states (1) if you face corruption issues after fixing key problems.
Frequently Asked Questions
Why does apt-key say "deprecated"?
The
apt-key command was deprecated because storing all trusted keys globally is insecure. Modern Linux distributions require keys to be stored in separate files within
/etc/apt/trusted.gpg.d/ to limit the impact of a compromised key.
How do I find the correct key ID?
You can find the key ID in the documentation of the repository you are adding. It is usually a long hexadecimal string. You can also list existing keys using
apt-key list on older systems to see what is currently installed, though this command is being phased out.
Can I use gpg directly instead of apt-key?
Yes, you can use
gpg to export keys manually. However, the recommended method is to download the key file and place it in
/etc/apt/trusted.gpg.d/. This avoids the complexity of managing keyrings manually and ensures compatibility with
apt's internal mechanisms.
What if the keyserver is unreachable?
Check your network configuration and firewall settings. Ensure that outbound HTTP traffic on port 80 is allowed. If the server is down, wait and retry later, or try an alternative keyserver if one is provided by the repository maintainer.
Is it safe to remove old keys?
It is generally safe to remove unused keys from
/etc/apt/trusted.gpg.d/. However, do not remove keys for repositories you actively use. Always back up your key directory before making changes to prevent accidental loss of critical authentication data.