Jotunheim.
Provisioning and recovering a Kali Linux lab VM.
Problem.
A security workspace should be easy to bring up again after experiments or updates. Getting Kali to boot was the first step; making its image, access, storage, and recovery procedure understandable was the more useful work.
Implementation.
- 01
Provisioned an official Kali cloud image after checksum verification. Used cloud-init for key-based access and the QEMU guest agent, with deliberate resource sizing and autostart disabled for an on-demand lab.
- 02
Moved the boot disk to available storage without deleting the original. Documented the active disk and retained copy so rollback does not depend on remembering what was moved.
- 03
Recovered networking through the guest agent after a rolling upgrade left the interface down. Traced the failure to a missing generated network definition and persisted a working configuration.
- 04
Investigated an apparent SSH authentication failure as a separate host-identity problem. Verified the regenerated host key through the trusted hypervisor channel before correcting the stale client record.
Result.
Provisioned and verified a working Kali lab with administrative SSH access, a functioning guest agent, recovered networking, and a documented rebuild procedure. This case study covers the lab foundation and recovery work; exercise writeups are a separate next step.
Documented image checksum checks, guest-agent and service checks, successful administrative key-based login, and network recovery. The original disk was retained. Verification covers environment provisioning and recovery; completed exercise writeups are outside this case study.
What I learned.
The error closest to the user is not always the cause. An SSH failure can come from host-key verification, and a network outage can come from boot-time configuration generation. A second observation channel makes both failures easier to diagnose without weakening trust checks.
Questions about this project?
Email Binh ↗