Kali Linux Ethical Hacking, Part 8: Harden Your Own Kali Host
Series: Kali Linux Ethical Hacking, Part 8. Previous: Part 7, auditing your own lab passwords. Earlier: Part 6, reading your own lab traffic.
To harden Kali Linux on a VM you own, take a snapshot first, switch SSH to key login, allow SSH only from your host only subnet with UFW, recheck listening ports with ss, and write a short fix list. You also practise how to undo each change so you are never locked out of your own lab.
Where we are: This is still the Part 1 lab: Kali at 192.168.56.102 and lab-web-01 at 192.168.56.101 on a host only network, already mapped, tested, audited, updated and captured in Parts 2 to 6. In Part 7 you recovered a weak password on a throwaway Kali account with John, fixed it, removed the account and shredded the hashes. Now you lock that same VM down so password SSH is not an option at all.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Changing firewall or SSH settings on a computer, network or account without permission is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. Only harden systems you own, or systems where you have clear written permission from the owner before you start.
Everything below runs on your own Kali VM from Part 1, on a host only lab network. Do not point these steps at shared servers, cloud boxes you don’t control, or anyone else’s SSH.
Why harden the machine you attack from?
Kali is a toolkit. If it is left open, it becomes a target. Parts 2 to 7 taught you to map, test and audit your own lab. This part turns the same tools inward: fewer listeners, keys instead of passwords, and a firewall that only trusts the lab subnet.
My day job sits close to network detection and response, so I think of every machine you test from as something worth locking down too. A hardened lab VM is a simple habit that keeps your practice machine from becoming someone else’s pivot.
Which tool versions are current?
Checked on 26 October 2026:
- OpenSSH server: the Kali package tracker lists
1:10.6p1-1in kali-rolling. Your version may be newer by the time you read this. - UFW: kali-rolling has
0.36.2-10. - fail2ban: available in kali-rolling as
1.1.1-1.
Keep packages current with the routine in Part 5.
What do you need before you start?
- Your Kali VM with a host only adapter on a subnet such as
192.168.56.0/24. The examples use192.168.56.102for Kali and192.168.56.101for a lab peer. Replace them with yours. - A second lab host or the hypervisor host that can SSH into Kali on that subnet, so you can test before you tighten anything.
- SSH running on Kali. If it is not running yet, start it with
sudo systemctl enable --now ssh. - VirtualBox (or similar) so you can take a snapshot.
- A notes folder:
NOTES=~/lab-notes/$(date +%F)/harden
mkdir -p "$NOTES" && chmod 700 "$NOTES"
cd "$NOTES"
How do you prepare before changing SSH or the firewall?
Step 1: Take a snapshot
Shut Kali down, then on your computer (not inside Kali):
VBoxManage snapshot "kali-linux-2026.2" take "pre-harden-$(date +%F)"
VBoxManage snapshot "kali-linux-2026.2" list
Use your own VM name, as shown by VBoxManage list vms.
Expected output: a progress bar to 100 percent, then a list showing the new snapshot. If anything locks you out later, restore it with the VM off.
Step 2: Record what is listening now
Start Kali and save a baseline:
sudo ss -ltnup | tee 01-listeners-before.txt
hostname -I | tee -a 01-listeners-before.txt
Expected output (sample):
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=6))
192.168.56.102 10.0.2.15
Note every port that is not loopback. You will compare this list after the firewall is on.
How do you switch SSH to key login on your own Kali?
Step 3: Create a lab only SSH key on your admin machine
On the machine you will SSH from (another lab VM or your host), run:
ssh-keygen -t ed25519 -f ~/.ssh/kali_lab_ed25519 -C "lab-only-$(date +%F)"
Expected output: prompts for a passphrase. Use a real passphrase. Then two files appear: kali_lab_ed25519 (private) and kali_lab_ed25519.pub (public). Keep the private key off shared drives.
Step 4: Install the public key on Kali and test login
From the admin machine:
ssh-copy-id -i ~/.ssh/kali_lab_ed25519.pub kali@192.168.56.102
ssh -i ~/.ssh/kali_lab_ed25519 kali@192.168.56.102 'echo key-login-ok'
Expected output: key-login-ok. If that fails, stop. Do not disable password login until this works.
Step 5: Harden sshd only after the key works
On Kali, add a drop in config so the main file stays untouched:
sudo tee /etc/ssh/sshd_config.d/20-lab-harden.conf >/dev/null <<'CONF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
CONF
sudo sshd -t && sudo systemctl reload ssh
Expected output: no output from sshd -t means the config is valid. Then confirm from the admin machine:
ssh -i ~/.ssh/kali_lab_ed25519 kali@192.168.56.102 'echo still-ok'
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no kali@192.168.56.102
Expected output: the first command prints still-ok. The second should fail with a permission or authentication error, because passwords are off.
How do you allow SSH only from the host only subnet with UFW?
Step 6: Install UFW and set a default deny
sudo apt update
sudo apt install -y ufw
ufw version
sudo ufw default deny incoming
sudo ufw default allow outgoing
Expected output (sample): a version line such as ufw 0.36.2, then confirmations that the defaults were set. Incoming deny means nothing is accepted until you add a rule.
Step 7: Allow SSH from the lab subnet only, then enable
sudo ufw allow from 192.168.56.0/24 to any port 22 proto tcp comment 'lab-ssh'
sudo ufw --force enable
sudo ufw status verbose | tee 02-ufw-status.txt
Expected output (sample):
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN 192.168.56.0/24 # lab-ssh
Replace 192.168.56.0/24 with your real host only subnet. --force skips the interactive warning that enabling UFW can disrupt SSH. You already have a working key login and a snapshot, which is why this is safe to do now.
Step 8: Confirm SSH still works from a lab peer
From the admin machine on the host only network:
ssh -t -i ~/.ssh/kali_lab_ed25519 kali@192.168.56.102 'sudo ufw status | head -3'
Expected output: a sudo password prompt for the kali user, then Status: active and the rule table header. (ufw status needs root, which is why sudo and -t are there.) If this fails, restore the snapshot from Step 1 rather than guessing.
How do you recheck listening ports and optional fail2ban?
Step 9: Recheck listeners after the firewall
On Kali:
sudo ss -ltnup | tee 03-listeners-after.txt
diff -u 01-listeners-before.txt 03-listeners-after.txt || true
Expected output (sample): SSH still listening on port 22. UFW filters traffic but does not close listening sockets, so the two lists usually match. Use the diff to spot anything you did not expect. Anything unexpected that belongs to a lab service you own can be stopped. Example for a leftover Juice Shop bound to all interfaces:
sudo docker ps --filter publish=3000
# if it shows 0.0.0.0:3000, stop it or rebind to 127.0.0.1 as in earlier parts
Do not stop services you do not recognise without checking what they are. The goal is fewer surprise listeners on your own host, not a broken lab.
Step 10: Optional fail2ban for sshd
fail2ban is in Kali main (1.1.1-1 as of 26 Oct 2026). It is optional for a quiet host only lab, but useful if you ever expose SSH more widely on a machine you own:
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd 2>&1 | tee 04-fail2ban.txt
Expected output (sample): a jail named sshd with a filter and a ban action. If status sshd errors because the jail is not enabled yet, check /etc/fail2ban/jail.d/ after install. Skip this step entirely if you prefer a minimal lab.
How do you record findings and undo safely?
Step 11: Write a short fix list
cat > 05-fix-list.md <<'FIX'
# Harden own Kali, DATE
| # | Change | Evidence | Status |
|---|--------|----------|--------|
| 1 | SSH key login only | 20-lab-harden.conf, key-login test | done |
| 2 | UFW allow 22 from host only subnet | 02-ufw-status.txt | done |
| 3 | Listener review | 01 vs 03 ss output | done |
| 4 | fail2ban sshd (optional) | 04-fail2ban.txt | done or skipped |
FIX
sed -i "s/DATE/$(date +%F)/" 05-fix-list.md
cat 05-fix-list.md
Expected output: the table with today’s date. Keep this with the same habit as Part 4.
Step 12: Know how to undo without a full snapshot restore
If you need password login again for a moment:
sudo rm /etc/ssh/sshd_config.d/20-lab-harden.conf
sudo sshd -t && sudo systemctl reload ssh
To stop the firewall:
sudo ufw disable
sudo ufw status
Expected output: Status: inactive. Prefer the snapshot restore if you are unsure what changed. Part 9 will pack these findings into a short report you can reuse.
What to do next
- Complete Steps 1 to 5 and prove key login before you touch UFW.
- Enable UFW with the lab subnet rule in Steps 6 to 8 and retest from a lab peer.
- Diff the listener lists in Step 9 and stop only services you own and understand.
- Decide on fail2ban in Step 10.
- Save the fix list and the undo commands.
- Keep packages updated with Part 5.
- After a weak password finding from Part 7, confirm password SSH is actually off.
- For more open source hardening ideas, browse my security GitHub repos roundup for October 2026.
Next up: In Part 9 you pack every finding from this lab into a short report and an evidence folder, using simple templates only, with no AI in the loop.
Leave a comment