Setting up keys for a local repository on a new ubuntu 20.10 virtual machine, I got a message that apt-key add was deprecated and I should read the apt-key
(8) man page. The apt-key
(8) man page is a collection of words strung together, but if it contains information I can't winkle it out. Can anyone tell me what, exactly, I should type on my terminal instead of:
apt-key add name-of-file
The command does apparently still work after honking at me, so I was able to proceed, but would like to know what I'll need to do in the future.
You need to know why
apt-key add
is deprecatedAll of the answers so far work around the symptom ("Don't use
apt-key add
") but fail to address the actual problem that led toapt-key add
being deprecated. The problem is not a question of appending a key to one big keyring fileetc/apt/trusted.gpg
vs manually putting single-key keyring files into the directory/etc/apt/trusted.gpg.d/
. These two things are equivalent, and doing either one is a huge security risk.The problem is that any key you add to either of the above is completely and unconditionally trusted by apt. This means that when installing any package from any repo (including the official distro repos), apt will happily accept the package being signed by any of those trusted keys (whether the key belongs to the repository the package is coming from or not). This weakens the assurance provided by the package signing mechanism against malicous packages being injected into the official Ubuntu mirrors network.
What we want to do instead is configure apt to accept signatures from a third-party repository only on packages being installed from that repository — no cross-signing. Apt's default pinning rules give higher priority to official distro repos, which (in conjunction with proper key management) offers some protection against third-party repos replacing distro-provided packages. (At least, I think that's default. You can use
apt-cache policy
to inspect the current pin priorities, and if needed you can adjust pinning based onorigin
to achieve this effect. Seeman apt_preferences
for details.)The instructions given in Ugo Delle Donne's answer for converting the key to the (legacy) keyring v4 format that apt will accept are correct and helpful, but that's only half of the solution. I'll reiterate them here (cleaned up slightly) so all the steps are consolidated in one place:
wget https://host.domain.tld/path/to/<keyfile>.<ext>
(No need for
-O
or>
;wget
defaults to saving the file in your current directory with the same filename it has on the server.)file <keyfile>.<ext>
gpg
supports a number of key formats, so if your key is in a different format, convert it by importing it into a temp keyring, then exporting it again:gpg --no-default-keyring --keyring ./temp-keyring.gpg --import <keyfile>.<ext>
gpg --no-default-keyring --keyring ./temp-keyring.gpg --export --output <your-keyfile-name>.gpg
rm temp-keyring.gpg
Now that you have your converted key, do not add it to
apt
's trusted keystore by copying it into/etc/apt/trusted.gpg.d/
. Instead, put it somewhere like/etc/apt/keyrings/
. (You might need to create thatkeyrings
directory first.) There's nothing special about that location, it's just a convention recommended byman 5 sources.list
in Ubuntu 22.04 and a related Debian Wiki entry.At this point, nothing has changed and
apt
doesn't know the key exists. The last step is to modify the specific.list
file for the repository to tell apt where to find the key for that specific repo./etc/apt/sources.list.d/<example>.list
, and in betweendeb
and the url, add[signed-by=/etc/apt/keyrings/<your-keyfile-name>.gpg]
Now apt will accept that key's signature for all packages in that repo and only that repo.
Notes:
/etc/apt/trusted.gpg.d/
, you cancopymove them to/etc/apt/keyrings/
as-is, and then update all the corresponding.list
files so each one has asigned-by
field pointing to its own key./etc/apt/trusted.gpg
keyring file beyond the official repo keys, this answer details the steps to locate and remove them. You can then follow all the same steps above to set them up the safer way. (Exporting them from that keyring is also possible, but the exact steps are left as an exercise for the reader.)gpg --no-default-keyring --keyring <output-file-name>.gpg --keyserver <some.keyserver.uri> --recv-keys <fingerprint>
Deb822
format using individual.sources
files instead of.list
files. It's more work, but personally I find the result far more readable.Sources:
I stumbled on the same problem and luckily some other question lighted the way. In my example I was trying to add a teamviewer repository to a recent Kali linux and I was being blocked by the key verification.
I'm quite sure there's a more elegant way to do this but the following steps helped me fix the problem:
Download the relevant key
wget -O - https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc > ~/teamviewer.key
Verify the type of file
file ~/teamviewer.key
it should be PGP public key block Public-Key (old)
Create a keyring
gpg --no-default-keyring --keyring ./teamviewer_keyring.gpg --import teamviewer.key
This file is still not a valid key that can be added to /etc/apt/trusted.gpg.d/ since it's a keyring, but from the keyring we can extract the key with
gpg --no-default-keyring --keyring ./teamviewer_keyring.gpg --export > ./teamviewer.gpg
This file is the key you want to move to the trusted key folder
sudo mv ./teamviewer.gpg /etc/apt/trusted.gpg.d/
happy
sudo apt update
!!!The reason for this deprecation is because using
apt-key add
simply appends the gpg key to the trusted global APT keyring. It's similar to the preferred method of addinglocal_repo.list
to/etc/apt/sources.list.d/
instead of usingadd-apt-repository dep /link/to/repo version
, which appends the message to the globalsources.list
file.I think it's a bit more awkward to understand than using the .d folder, but essentially we want to get the gpg key into a standalone keyring file, then point to this keyring file in the source listing. The default keyring file location is
/usr/share/keyrings
, and it can be a .asc or .gpg file. I'm not sure the difference but I do know the global keyring files are binary files, not plaintext.For example:
Using generic names can be a bit hard to understand sometimes, so here is an example of installing mongoDB:
Get the MongoDB gpg key and add it to a new keyring file
Add a source entry for apt, pointed to this new keyring
Install mongodb from this newly added repo
sudo apt install -y mongodb-org
Reference
This is still new to me, but most of what I know came from this excellent answer in the unix SE
I created a shell script that can download and install keys to be used with
[signed-by=]
declaration insources.list
.It's available on github.com/ameinild/add-apt-key.
As a direct workalike, replace
apt-key add
withgpg --dearmor
:curl [KEYURL] | sudo gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/[KEYFILE].gpg
However, this is not recommended (other than as a workalike to apt-key) since all keys in the trusted directory are unconditionally trusted; it is better to put the output in a (non-globally) trusted directory (as others have suggested), and have each source specify which key(s) to trust, individually.
Keys for use by
apt
are stored in/etc/apt/trusted.gpg.d/
.apt-key
managed these keyrings for you, but now that it's deprecated you need to choose a suitable file name<KEYRING>
for the keyring yourself.If you have the key already as a local file
<FILE>
, runTo directly read the key from
<URL>
, runNote: the prefix
gnupg-ring:
before the keyring name is required to create the keyring in theapt
compatible (legacy) v4 format, rather than the (newer) keybox v1 format.All of the answers here are great, What I'm sharing here is what I took from all of these answers, and automated to make setting up machines easier for me.
Although adding an apt source is a rare occasion per machine, it still is something I do on multiple machines, cloud machines, etc...
The following is a bash script I wrote for myself to add the stack of APT sources on an ubuntu/pop-os based machine I use for DevOps work:
NOTE: Don't just copy paste, if you don't understand what's going on - ask. These are the type of actions no person should take lightly.
My
add-my-apt-repos.sh
script (GH?):