A fresh Kali install boots straight into a working desktop, which makes it easy to skip the setup that keeps it working. The things to do after installing Kali Linux are mostly small. You pull the rolling updates, check which tool set you actually got and stop living in the shared kali account. Then you give the VM proper guest tools and a snapshot, and confirm your Wi-Fi adapter can do monitor mode before an engagement depends on it. Most of the hour it takes is waiting for packages.
This post-install checklist follows the order that avoids rework: update first, then metapackages, users, virtualization, kali-tweaks, wireless, keyboard and shell. If you haven’t installed yet, our Kali install walkthrough with screenshots covers the installer itself. I went through these steps again on Kali 2026.3 in October 2026, and every output block below comes from that lab VM; where a step depends on VirtualBox, VMware or a real USB adapter, the section says so.
Update Kali before you install anything else
Kali is a rolling distribution, so the ISO you installed from is already behind the day you boot it. Install extra tools from a stale index and apt asks the mirror for package versions that have already been replaced, which ends in 404 errors. Install them after apt update but before upgrading, and new tools get pulled against old libraries, the usual source of the “held broken packages” errors people post on forums. Refresh the package index first:
sudo apt updateOur lab VM had been built from the 2026.2 image and upgraded once, and even so the index alone was a 77.6 MB download, and apt reported 930 packages waiting:
Get:1 http://kali.download/kali kali-rolling InRelease [34.0 kB]
Get:2 http://kali.download/kali kali-rolling/main amd64 Packages [21.8 MB]
Get:3 http://kali.download/kali kali-rolling/main amd64 Contents (deb) [54.3 MB]
Get:4 http://kali.download/kali kali-rolling/contrib amd64 Packages [106 kB]
Get:5 http://kali.download/kali kali-rolling/contrib amd64 Contents (deb) [185 kB]
Get:6 http://kali.download/kali kali-rolling/non-free amd64 Packages [168 kB]
Get:7 http://kali.download/kali kali-rolling/non-free amd64 Contents (deb) [887 kB]
Get:8 http://kali.download/kali kali-rolling/non-free-firmware amd64 Packages [16.3 kB]
Get:9 http://kali.download/kali kali-rolling/non-free-firmware amd64 Contents (deb) [42.5 kB]
Fetched 77.6 MB in 9s (8,272 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
930 packages can be upgraded. Run 'apt list --upgradable' to see them.Use full-upgrade rather than plain upgrade. Kali’s metapackages regularly add and drop dependencies, and plain upgrade refuses to remove anything, so it leaves those packages held back. The -y skips the confirmation prompt; leave it off if you want to read the list first:
sudo apt full-upgrade -yBefore downloading, apt prints a summary. Ours wanted 2 GB and planned to remove six libraries that newer packages replace, which is exactly the part plain upgrade would have refused:
REMOVING:
libblosc2-7 libgvm22t64 libshiboken6-py3-6.10
libfalcosecurity0t64 libpyside6-py3-6.10 python3-pkg-resources
Summary:
Upgrading: 930, Installing: 27, Removing: 6, Not Upgrading: 0
Download size: 2,039 MB
Freed space: 363 MBRun this from a terminal on the Kali desktop, or inside tmux if you’re connected over SSH, so a dropped connection doesn’t take the upgrade down with it. Then let it finish without interruption. A full-upgrade that gets cut off halfway, by a closed laptop lid or a dropped session, leaves packages unpacked but not configured. The next apt command then refuses to run until you finish the job with sudo dpkg --configure -a followed by the same full-upgrade again. On our VM a run was killed at package 684 of 957, and those two commands picked it up and completed it cleanly.
The upgrade also leaves behind libraries nothing depends on any more. apt lists them at the top of its output, and removing them freed another 133 MB on our VM:
sudo apt autoremove -yA new kernel, a new libc or a new systemd only takes effect after a restart. Some packages also drop a flag file at /var/run/reboot-required when they need one, and ours had it after this upgrade, but don’t wait for the flag: reboot after any upgrade that touched the kernel, libc or systemd.
sudo rebootOnce you’re back at the desktop, confirm the release and the kernel you booted:
grep VERSION= /etc/os-release; uname -rThe release file still reads 2026.3 after the upgrade, because Kali only bumps it with a point release, even though the packages underneath are newer. The kernel line is the one that tells you which build you booted:
VERSION="2026.3"
7.1.5+kali-amd64From here on, a weekly sudo apt update && sudo apt full-upgrade -y keeps you current. Our guide to upgrading Kali Linux to the latest version covers moving between point releases and recovering from an upgrade that stops halfway.
Error: “Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5”
If apt update fails with that line, your install predates the archive signing key Kali rotated in 2025. The old key is still in your keyring, but the repository is now signed with the new one, so apt can’t verify anything and refuses to update. Images from 2025.1c onward already carry the new key, which is why a current install never sees this. The fix from the Kali announcement replaces the keyring file. Our VM already had the new key, so we only checked its hash, not this download:
sudo wget https://archive.kali.org/archive-keyring.gpg -O /usr/share/keyrings/kali-archive-keyring.gpgCheck the file before you trust it. Kali publishes the SHA1 603374c107a90a69d983dbcb4d31e0d6eedfc325, and the keyring on our updated VM matched it:
sha1sum /usr/share/keyrings/kali-archive-keyring.gpgThe hash comes back first on the line, followed by the path.
603374c107a90a69d983dbcb4d31e0d6eedfc325 /usr/share/keyrings/kali-archive-keyring.gpgWith a matching hash, run sudo apt update again and it goes through.
Check which kali-linux metapackage you have
Kali does not install tools one by one. It groups them into metapackages, and the installer’s software screen decides which ones you start with. People often assume they got “everything” and then wonder why a tool from a tutorial is missing. List what’s actually installed:
dpkg -l | grep -E '^ii +kali-(linux|tools)'Our VM had the standard desktop set: kali-linux-default, which pulls in kali-linux-headless, kali-linux-core and the kali-tools-top10 group:
ii kali-linux-core 2026.4.2 amd64 Kali's core packages
ii kali-linux-default 2026.4.2 amd64 Kali's default toolset
ii kali-linux-firmware 2026.4.2 amd64 Kali's default firmware files
ii kali-linux-headless 2026.4.2 amd64 Kali's default headless tools
ii kali-tools-top10 2026.4.2 amd64 Kali's top 10 toolsThose groups nest, so each step up the table below includes everything in the rows above it. The sizes are Kali’s own measurements for an Xfce install from its installation sizes page, taken on an older release, so treat them as rough guides rather than exact numbers:
| Metapackage | What it adds | Xfce install size |
|---|---|---|
kali-linux-core | The base system with no pentest tools beyond netcat and tcpdump | 3.7 GB |
kali-linux-default | The desktop image set: Nmap, Metasploit, Burp Suite, aircrack-ng, hashcat, Wireshark and the rest of the usual toolkit | 13 GB |
kali-linux-large | The older, bigger default selection | 20 GB |
kali-linux-everything | Every metapackage and many extra tools | 34 GB |
Most people should stay on kali-linux-default and add a focused group when a job needs it, because kali-linux-everything nearly triples the disk use and the weekly upgrade time for tools you may never open. For wireless work, the kali-tools-802-11 group is the usual add-on. Ask apt what it would cost before you commit; --assume-no prints the full plan and then answers no for you:
sudo apt install --assume-no kali-tools-802-11On top of kali-linux-default, it wanted 50 packages, including airgeddon, bettercap, hcxdumptool, hostapd-wpe and mdk4, for a 78.3 MB download:
Summary:
Upgrading: 0, Installing: 50, Removing: 0, Not Upgrading: 0
Download size: 78.3 MB
Space needed: 322 MB / 59.9 GB available
Continue? [Y/n] N
Abort.When the summary looks right, run the same command without --assume-no. You can also browse and toggle these groups from a menu in kali-tweaks, which comes up later in this checklist.
Create your own non-root user
Kali has used a regular account instead of root since 2020.1. The installer images ask you to create that account, while the live image and the prebuilt VirtualBox, VMware and QEMU images ship a kali user whose password is also kali. If you started from a prebuilt image, everyone who has read the default credentials page knows your login, so change it right away:
passwdA personal account is the better fix, because your shell history, browser profile and tool configs then live under a name you chose, and you can lock or delete the shared one later. Create it with adduser, which asks for a password and an optional full name:
sudo adduser lornaThis is the part that trips people up. The new account does not get any of the extra groups the installer gave the first user, so check what it actually has:
id lornaThe new user is only in its own group and users.
uid=1002(lorna) gid=1002(lorna) groups=1002(lorna),100(users)Without sudo you cannot install anything, without wireshark you cannot capture packets unless you run Wireshark as root, and without dialout and plugdev serial adapters and some USB radios refuse to open. The original kali user on our VM was in all of these plus a dozen more. Add the ones that matter for day-to-day work:
sudo usermod -aG sudo,wireshark,dialout,plugdev,netdev lornaRun id lorna again and the groups are there.
uid=1002(lorna) gid=1002(lorna) groups=1002(lorna),20(dialout),27(sudo),46(plugdev),100(users),101(netdev),118(wireshark)Group changes only apply to new logins, so log out of the desktop and sign in as the new user before testing. A quick sudo whoami should ask for your password once and print root. If you’d rather not type a password for every sudo call, the switch Kali’s sudo documentation gives for that is sudo apt install -y kali-grant-root && sudo dpkg-reconfigure kali-grant-root, which adds you to a passwordless group instead of editing sudoers by hand. I’d leave it off on a laptop you carry to client sites.
Install guest tools for VirtualBox or VMware
If Kali runs in a VM, guest tools give you a desktop that resizes with the window, a shared clipboard and drag and drop. The installer detects the hypervisor and usually installs them for you, so check before installing anything:
systemd-detect-virtIt prints oracle under VirtualBox, vmware under VMware Workstation or Fusion, and kvm under Proxmox, virt-manager or GNOME Boxes. Our lab VM runs on Proxmox:
kvmMatch the answer to one package set. The VirtualBox and VMware rows are the packages Kali’s virtualization docs name; the KVM row is what our Proxmox VM had installed. On Proxmox, the agent also needs QEMU Guest Agent enabled under the VM’s Options tab on the host side, followed by a full stop and start of the VM from Proxmox.
| systemd-detect-virt says | Hypervisor | Install |
|---|---|---|
oracle | VirtualBox | virtualbox-guest-x11 |
vmware | VMware Workstation, Fusion, ESXi | open-vm-tools-desktop and fuse |
kvm | Proxmox, virt-manager, GNOME Boxes | qemu-guest-agent and spice-vdagent |
apt-cache shows in one call whether each package is installed and which version the repository has, so you can see at a glance whether the installer already did the work:
apt-cache policy virtualbox-guest-x11 open-vm-tools-desktop qemu-guest-agent | grep -E '^[a-z]|Installed|Candidate'On our KVM guest only the QEMU agent was installed, which is the right result: the VirtualBox and VMware packages would do nothing there. On VirtualBox you’d want the first one to show a version instead of (none):
virtualbox-guest-x11:
Installed: (none)
Candidate: 7.2.20-dfsg-2
open-vm-tools-desktop:
Installed: (none)
Candidate: 2:13.0.10-1.1
qemu-guest-agent:
Installed: 1:11.1.2+ds-3
Candidate: 1:11.1.2+ds-3On VirtualBox, reinstall the guest package and reboot if the screen won’t resize:
sudo apt install -y --reinstall virtualbox-guest-x11On VMware, the equivalent pulls in the desktop agent that handles resizing and the clipboard:
sudo apt install -y --reinstall open-vm-tools-desktop fuseOur lab ran on Proxmox, so the VirtualBox and VMware commands above come from Kali’s docs and were not run on a VirtualBox or VMware host. Whichever one you use, keep 3D acceleration off in the VM settings, since Kali’s VirtualBox and VMware guides both say to leave it disabled. If you plan to use a USB Wi-Fi adapter inside the VM, check now that your hypervisor can pass a USB device through to the guest; the monitor-mode check further down depends on it. Our VirtualBox install guide covers the host side if you’re still setting that up.
Take a snapshot of the clean system
Now that the VM is updated, has your user and has working guest tools, freeze it. Kali gets broken in ways other distros don’t: a tool’s install script that overwrites a Python library, a lab exercise that rewrites iptables, a kernel module built against the wrong headers. Rolling back a snapshot takes a minute, and reinstalling plus repeating this checklist takes an hour. Shutting the VM down first gives you the cleanest snapshot, because nothing is half-written to disk and the hypervisor has no memory state to save:
sudo poweroffThen take the snapshot from the host. Each hypervisor puts it in a different place, and only the Proxmox route below was used on our lab VM:
- In VirtualBox, you select the VM, open its Snapshots view and click Take.
- In VMware Workstation, you use VM, then Snapshot, then Take Snapshot.
- In Proxmox, you open the VM’s Snapshots tab and click Take Snapshot, which works when the disk sits on snapshot-capable storage such as qcow2, LVM-thin, ZFS or Ceph.
- You name it with the date and what’s in it, such as
clean_2026_10_29, so you can tell the snapshots apart in six months.
On our Proxmox VM I took the snapshot with the guest still running, without its memory, and it finished in a few seconds. To prove it was worth having, I deleted the new user’s ~/.zshrc and put a hold on the nmap package, then rolled back. About a minute later the VM was up again with the file restored, and apt-mark showhold listed no holds. Take a fresh one before any lab that changes the system, and delete old ones you no longer need, because each snapshot keeps growing as the disk changes underneath it. On bare metal there’s no hypervisor to fall back on; there, a backup of your home directory and a USB installer in the drawer is the snapshot.
Run kali-tweaks
kali-tweaks is Kali’s menu for settings that otherwise mean editing several files by hand. It’s installed with the default desktop, and it runs in the terminal, so it works the same over SSH:
kali-tweaksVersion 2026.2.0 of kali-tweaks opens on a main menu with five sections. This is the screen from our VM, with the box lines drawn in plain ASCII and the empty rows removed:
+-----------------------------------------+ Main Menu +------------------------------------------+
| Hardening Configure the system for extra security |
| Metapackages Install specific subsets of tools for particular needs |
| Network Repositories Configure network repositories for APT sources |
| Shell & Prompt Configure the shell and command prompt |
| Virtualization Additional configurations for Virtual Machines |
| <Select> <Quit> |
+------------------------------------------------------------------------------------------------+
<Tab>/<Alt-Tab> between elements | <Space> selects | <F12> next screenMove with the arrow keys, press Enter to open a section and Space to tick an option, then Tab to Apply. Anything that changes the system asks for your sudo password inside the menu. On a current install the sections hold the following:
- Hardening holds the Restrict dmesg and Privileged Ports kernel switches, plus a Samba client option ticked for Wide Compatibility.
- Metapackages lets you tick tool groups on or off, after it runs
apt-get updatefor you. - Network Repositories adds the bleeding-edge and experimental branches, picks the mirror and switches apt to HTTPS.
- Shell & Prompt changes the prompt style and login shell, or resets your shell config files.
- Virtualization detects your hypervisor and adds the VMware shared-folder scripts when they apply.
The Virtualization section on our KVM guest only printed “Virtualization detected: KVM” and “Your system is already configured for this virtualization technology”, with nothing to change.
Network Repositories started with HTTP and the community mirror selected, with both extra branches off. Switching to HTTPS is the one change I’d make on day one, because it hides which packages you install from anyone watching the network (the package signatures already stop tampering, so this is about privacy, not integrity). Leave bleeding-edge and experimental unticked. They’re where packages land before the normal testing, and mixing them into a machine you rely on for work is how a weekly update turns into an afternoon of fixing.
Check your Wi-Fi adapter for monitor mode
Wireless testing needs two things most built-in laptop cards can’t do: monitor mode, which captures every frame in the air, and packet injection, which sends frames of your own. Inside a VM there’s a third problem, because the hypervisor only gives the guest a virtual Ethernet card. The first command tells you which situation you’re in:
sudo airmon-ngBefore any adapter was passed through, our VM showed an empty table, and iw dev printed nothing at all. That is normal for a VM, and it does not mean Kali is missing a driver:
PHY Interface Driver ChipsetAn empty table in a VM means you need a USB adapter passed through to the guest; Kali’s wireless troubleshooting page puts it plainly, since every PCI card is virtualized away. On bare metal, an empty table means the card has no driver, or rfkill list shows it blocked. Once an adapter appears, ask the driver which modes it supports:
iw list | grep -A10 'Supported interface modes'To capture real output without real hardware, I loaded the kernel’s mac80211_hwsim module, which creates a simulated radio with the same software stack a USB card uses. A capable adapter lists monitor among its modes, like this:
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
* P2P-device
* outside context of a BSSIf monitor isn’t on that list, no setting in Kali will add it, and the adapter is the wrong one for the job. Our tested Wi-Fi adapters for Kali Linux lists the chipsets that pass both checks with the drivers already in the Kali kernel. When the mode is there, put the card into monitor mode with airmon-ng:
sudo airmon-ng start wlan0airmon-ng warns that NetworkManager and wpa_supplicant are running, then creates a new interface named wlan0mon in monitor mode:
The ?????? driver and the “report this” line are the simulated radio talking; a real adapter shows its driver and chipset there instead. The process warning is the one to act on. sudo airmon-ng check kill stops both processes so they can’t hop channels under you. It also stops NetworkManager for every interface, so only run it when you can live without your other connections for a while. Then test injection, which sends probe requests and counts the access points that answer.
sudo aireplay-ng --test wlan0monOur simulated radio had nothing to talk to, so it came back with no answers.
06:19:37 Trying broadcast probe requests...
06:19:39 No Answer...
06:19:39 Found 0 APs“No Answer” with zero APs means either nothing is in range or the card can’t inject, so run the test next to a router you own before blaming the hardware. An adapter is ready for wireless work when it passes all four checks:
- It shows up in
sudo airmon-ngwith a real driver and chipset name. - Its
iw listoutput includesmonitorunder supported interface modes. - It comes back from
airmon-ng startwith an interface of type monitor. - Its injection test prints “Injection is working!” next to your own access point.
A card that fails the second check will never pass the rest, so stop there and pick another adapter. When you’re done testing, sudo airmon-ng stop wlan0mon puts the card back into managed mode, and sudo systemctl start NetworkManager brings networking back if you killed it.
Set the keyboard layout
Kali uses a US layout unless you picked another one in the installer, and our prebuilt QEMU image came up as US too. A wrong layout is worse than an annoyance on Kali, because the symbols that move between layouts, such as the pipe, the at sign and the hash, are the ones in every command and password. Check what is set:
localectl statusA fresh prebuilt image reports US.
System Locale: LANG=en_US.UTF-8
VC Keymap: (unset)
X11 Layout: us
X11 Model: pc105On most distros you would fix this with localectl set-x11-keymap. On Kali that command appears to work, then quietly undoes itself. Kali keeps the keyboard settings in /etc/default/keyboard, and a Debian boot rule turns /etc/vconsole.conf back into a link to that file every time the system starts. localectl writes its own vconsole.conf over the link, so localectl status shows your new layout until the next reboot, when it says us again. We set UK twice that way on our VM and lost it on both reboots. Edit the file Kali actually reads instead:
sudo vim /etc/default/keyboardChange the layout and options lines. This example sets UK with US as a second layout, and Alt+Shift flips between them. Swap gb for the two-letter code of your own layout.
XKBMODEL="pc105"
XKBLAYOUT="gb,us"
XKBVARIANT=""
XKBOPTIONS="grp:alt_shift_toggle"That file is read at boot, so the desktop you’re typing in right now keeps the old layout until you log in again. Apply it to the current Xfce session as well, so you don’t have to restart to test it:
setxkbmap -layout gb,us -option grp:alt_shift_toggleCheck the running session with setxkbmap -query, and it now shows both layouts.
rules: evdev
model: pc105
layout: gb,us
options: grp:alt_shift_toggleAfter a reboot, localectl status reported X11 Layout: gb,us with the toggle option, and the Xfce session came up with both layouts, which is the result the localectl route never kept. If you already tried localectl before reading this, there is nothing to undo: on our VM it left /etc/X11/xorg.conf.d/ empty, and the reboot threw its setting away.
Set up the Zsh shell and prompt
Kali switched its default shell to Zsh in 2020.4, with a two-line prompt, syntax highlighting and command suggestions from your history. That default only reaches the first user, though. The account we created with adduser came out with Bash:
getent passwd lornaThe last field is the login shell.
lorna:x:1002:1002:Lorna:/home/lorna:/bin/bashThe Kali .zshrc was already copied into the new home directory from /etc/skel, so only the shell needs changing. You don’t need sudo for your own account:
chsh -s /usr/bin/zshgetent passwd lorna ends in /usr/bin/zsh straight away, and the Kali prompt appears at your next login. To change how that prompt looks, open kali-tweaks, then Shell & Prompt, then Configure Prompt. The top of that screen on our VM, again redrawn in ASCII, offers three styles:
+---------------------------------------+ Command Prompt +---------------------------------------+
| |
| Prompt Style: |
| (*) Two Lines Dual blue line prompt |
| ( ) One Line Single blue line prompt |
| ( ) BackTrack Legacy BackTrack red prompt |
| Prompt Settings: |
| [*] Newline Add a new line between output and prompt |Two Lines is the default and fine on a wide monitor. One Line suits a small laptop screen or a split terminal, because the two-line prompt eats a row of every screen of output. These settings are written into your own ~/.zshrc, so each user sets them separately.
Two small changes to ~/.zshrc pay off quickly on a pentest box. Kali keeps 1,000 lines of history in memory and 2,000 in the file by default, which a single day of scanning can fill, and you’ll want old commands back when writing a report. Open the file:
vim ~/.zshrcFind the existing HISTSIZE and SAVEHIST lines and raise them, then add timestamps so you can tell when each command ran:
HISTSIZE=100000
SAVEHIST=50000
setopt extended_historyReload with source ~/.zshrc. The obvious way to see timestamps, history -i, fails on Kali with fc: event not found: -i, because Kali’s .zshrc aliases history to history 0 and the flag lands after the number. Call the builtin underneath it instead:
fc -li -3Each entry now carries the date and time it ran.
9 2026-10-29 06:31 fc -li -3
10 2026-10-29 06:31 exit
11 2026-10-29 07:09 id -unThe first two lines came from an earlier session and the last one from the current shell, which is the point: with timestamps saved to the file, you can still tell when each command ran days later when you write up a report.
Learn the tools you just installed
At this point your Kali install is updated, runs under your own account with the right groups, has guest tools and a clean snapshot to return to, and you know whether your Wi-Fi adapter can do monitor mode. What it does not come with is a way to learn the hundreds of tools kali-linux-default pulled in, and the menu won’t tell you which ones matter. Start with Nmap, since almost every engagement begins with a scan; our Nmap scanning guide for Kali works through it on a real network. When you’re ready to practise against targets you’re allowed to attack, build a pentest lab with Proxmox and Kali so your snapshots cover the victims too.
For a structured path rather than one tool at a time, a good book still beats a playlist of videos, because it explains why each step works and not only which flags to type. Our pick of the best Kali Linux books for beginners and pentesters splits them by where you’re starting from, from first-week fundamentals to the ones that assume you already run Burp and Metasploit every day.
