Kali Vagrant Rebuilt: Out With Packer, In With DebOS

August 21, 2025 Yanac

Vagrant files, *.box, are pre-configured Virtual Machines (VM) VM images, which when imported into HashiCorp’s Vagrant, allow for VMs to be interacted with via the command line.
You create, start, interact, stop, destroy VMs all without leaving the terminal. Think containers (Docker/Podman), but for VMs.

Previously we have been using HashiCorp’s Packer to generate our HashiCorp’s Vagrant images.
Packer is a wrapper, around whatever hypervisor you wish, and it will automate installing the OS (unattended setup via preseeding), run any commands or scripts, export the VM and finally compress it.
The down-side to Packer is that you need to have the chosen hypervisor installed on the host OS, you can’t cross-build. If you use Linux, you can’t build Window’s Hyper-V.

For a few years now , we have been using DebOS, to automate building our VMs. This has been working great for us.
Recently we realized: “Why do we have two different systems, for the same purpose?”.
A little bit of digging into “how to make a vagrant base box VM” boils down to just a few requirements:

Fix username (vagrant)
Fix/Known pubic SSH keys (default/standard insecure keypairs)
Able to perform superuser actions (sudo)

Simple really, just need to make sure that Vagrant can easy access the VM!
Optional items (and recommended), as it helps benefits user’s rather than Vagrant:

Known/Fix credentials (vagrant everywhere)
SSH tweaks (speed up for airgap networks)

All of this can be handled in a post-install step, which we have put into our Kali-VM build-script.

Now, we are building all of our VMs, automatically, in the same matter (Stock and Vagrant), all in the same infrastructure setup (Linux!).

Since Microsoft Windows 10 1607 / Server 2016, when exporting VMs, there would be 3 additional “binary” files, *.vmcx/*.vmrs included as well as an *.xml. As we were no longer exporting the VM from Hyper-V, but generating it outside of, we do not have these files.
Now, we could create a “template” binary which would act as a dummy marker.
But this didn’t sit right with us, we didn’t want to include items, especially binary files.

Out of the box, Vagrant expected those binary files and failed without them. However a merge request later to upstream, and support has been added. As a result, trying to use Kali 2025.2 or higher on Windows using Hyper-V, using vagrant older than v2.4.7 will NOT work. You need to use either an older Kali, different hypervisor, manually patch or to upgrade Vagrant to be v2.4.8 (released 2025-08-05) or higher.

As Packer is no longer generating our Vagrant VMs, we renamed the git repository (gitlab.com/kalilinux/build-scripts/kali-vagrant -> gitlab.com/kalilinux/build-scripts/kali-packer).
Finally, before sunsetting our Packer build-scripts, we did a refresh of these build-scripts one more time. We might not be using it, but that doesn’t mean you can’t.

Demo
After getting Vagrant and VirtualBox installed:
$ vagrant box add kalilinux/rolling
==> box: Loading metadata for box ‘kalilinux/rolling’
box: URL: https://vagrantcloud.com/api/v2/vagrant/kalilinux/rolling
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.
1) hyperv
2) libvirt
3) virtualbox
4) vmware_desktop
Enter your choice: 3
==> box: Adding box ‘kalilinux/rolling’ (v2025.2.1) for provider: virtualbox (amd64)
box: Downloading: https://vagrantcloud.com/kalilinux/boxes/rolling/versions/2025.2.1/providers/virtualbox/amd64/vagrant.box
box: Calculating and comparing box checksum…
==> box: Successfully added box ‘kalilinux/rolling’ (v2025.2.1) for ‘virtualbox (amd64)’!
$
$ vagrant box list
kalilinux/rolling (virtualbox, 2025.2.1, (amd64))
$
$ mkdir -pv vagrant-demo/; cd vagrant-demo/
mkdir: created directory ‘vagrant-demo/’
$
$ vagrant init –force –minimal kalilinux/rolling
[…]
$
$ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(“2”) do |config|
config.vm.box = “kalilinux/rolling”
end
$
$ vagrant up –provider virtualbox
Bringing machine ‘default’ up with ‘virtualbox’ provider…
==> default: Importing base box ‘kalilinux/rolling’…
==> default: Generating MAC address for NAT networking…
==> default: Checking if box ‘kalilinux/rolling’ version ‘2025.2.1’ is up to date…
==> default: Setting the name of the VM: vagrant-demo_default_1753960552589_87147
Vagrant is currently configured to create VirtualBox synced folders with
the `SharedFoldersEnableSymlinksCreate` option enabled. If the Vagrant
guest is not trusted, you may want to disable this option. For more
information on this option, please refer to the VirtualBox manual:
https://www.virtualbox.org/manual/ch04.html#sharedfolders
This option can be disabled globally with an environment variable:
VAGRANT_DISABLE_VBOXSYMLINKCREATE=1
or on a per folder basis within the Vagrantfile:
config.vm.synced_folder ‘/host/path’, ‘/guest/path’, SharedFoldersEnableSymlinksCreate: false
==> default: Clearing any previously set network interfaces…
==> default: Preparing network interfaces based on configuration…
default: Adapter 1: nat
==> default: Forwarding ports…
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running ‘pre-boot’ VM customizations…
==> default: Booting VM…
==> default: Waiting for machine to boot. This may take a few minutes…
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection reset. Retrying…
default: Warning: Remote connection disconnect. Retrying…
default: Warning: Connection reset. Retrying…
default: Warning: Remote connection disconnect. Retrying…
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest…
default: Removing insecure key from the guest if it’s present…
default: Key inserted! Disconnecting and reconnecting using new SSH key…
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM…
default: The guest additions on this VM do not match the installed version of
default: VirtualBox! In most cases this is fine, but in rare cases it can
default: prevent things such as shared folders from working properly. If you see
default: shared folder errors, please make sure the guest additions within the
default: virtual machine match the version of VirtualBox you have installed on
default: your host and reload your VM.
default:
default: Guest Additions Version: 7.0.20
default: VirtualBox Version: 7.1
==> default: Mounting shared folders…
default: /tmp/vagrant-demo => /vagrant
$
$ vagrant ssh
Linux kali 6.12.25-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.12.25-1kali1 (2025-04-30) x86_64
The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
┌──(vagrant㉿kali)-[~]
└─$

Cheat-Sheet
vagrant box add kalilinux/rolling –force –clean –provider virtualbox –box-version 2025.2.1
mkdir -pv kali-vagrant/ && cd $_
vagrant init kalilinux/rolling –force –minimal –output – –box-version 2025.2.1 | tee Vagrantfile
vagrant up –provider virtualbox
vagrant ssh