This post discusses a technical problem that I very recently resolved. The mission is to load Kali Linux in a Virtual Box hosted by a Windows 8.1 laptop. After installing Kali in its virtual machine (VM), the next step is to update and upgrade the operating system. All of this is accomplished using
apt, high-level commandline interface for the package management system. Now, what makes this all so interesting is that before I started this, I couldn’t even spell
apt, much less know what it means or how it does its work. I’m doing all this work by following instructions in a pdf file.
So, the command to update and upgrade the Kali Linux operating system is
apt-get update && apt-get update -y.
apt responded with:
Get:1 http://archive-5.kali.org/kali kali-rolling InRelease [30.5kB]
Err:1 http://archive-5.kali.org/kali kali-rolling InRelease
The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linu Repository <firstname.lastname@example.org>
Reading package lists... Done
W: GPG error: https://archive-5.kali.org/kali kali-rolling InRelease: The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <email@example.com>
E: The respository 'http://archive-5.kali.org/kali kali-rolling InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for respository creation and user configuration details.
Not what I was looking for. The search for the answer began with the author of that pdf recipe I was following. Give the author credit, he did finally send the correct solution to the problem. But I was impatient and needed to be smarter about the commands I was running. The next step was RTFM … read the feckless manuals.
Reading the manpage for apt-secure(8) was intimidating. The job of apt-secure is to prevent unauthorized altered archives from being circulated in the wide, wide world and masquerading as the genuine article. I will return to that manpage in the near future and study it very closely until I make it all clear to myself. But, at the end of the day, the solution to this problem was not found here.
The Stack Exchange actually answered the mail for me. On their Unix and Linux page, marshki got me in the right neighborhood with a recommendation to first update the signature
sudo apt-key adv --keyserver http://http.kali.org --recv-keys ED444FF07D8D0BF6,
That made sense to me. The string,
ED444FF07D8D0BF6, figured prominently in the error messages I received. Intuitively this must be the key itself, or the key identifier. As it turned out though, this didn’t do the trick.
The follow on post, by Steve (and edited recently by PeterH) actually solved the riddle.
apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6
Clearly, this is going to work better when I go to the correct key server. And I find it very interesting that of the eight hexadecimal characters in the key signature, the last four (7D8D0BF6) appear to corelate to the receive keys.
Once the correct keys were obtained from the correct key server, I was able to update and upgrade the Kali installation.
Here are some final observations:
Nothing, but nothing, ever gets done without a lot of very hard work.
It is always a risky practice to attempt to simply “follow a recipe”. Read the procedure, understand what the commands are doing, and pay attention to detail.
Kali is a specialized tool, an off-spring of debian Linux, designed for ethical hackers to perform penetration testing.