Harden a Linux Server

Secure a Linux server with key-only SSH, a firewall, and live log monitoring.

Introduction

30 Second Summary

Every server connected to the internet faces constant automated attacks. Bots scan for open ports and try thousands of password combinations per hour, hoping to find one that works.

In this project, you will harden a Linux server step by step. You will start with a basic password-based SSH connection, witness its vulnerabilities firsthand, then lock it down with cryptographic keys, a firewall, and real-time log monitoring.

What You'll Build

Picture this: you type one command from your Windows machine, land on your Linux server instantly with no password prompt, and know that anyone without your private key gets turned away at the door.

By the end of this project, you'll have:

  • A working SSH connection from Windows to your Kali VM that authenticates with a cryptographic key pair instead of a password.
  • A UFW firewall actively blocking all incoming traffic except SSH, with status commands to prove it.
  • A live log stream showing every login attempt in real time so you can spot suspicious activity the moment it happens.
  • Secret Mission: Change the default SSH port and add rate limiting to your firewall to throttle brute-force attempts.

Are there any prerequisites?

You need basic Linux terminal comfort (commands like cd, ls, cat, chmod). You also need a Kali Linux VM and a Windows 11 machine.

Before We Start

Before diving into your server, let's lock in what you're about to harden and why it matters. This is your moment to commit to the mission: transforming a vulnerable Linux machine into one that only you can access.

Set Up SSH Access

SSH is the standard way to remotely control a Linux server from another machine. Before you can secure anything, you need a working connection between your Windows machine and your Kali VM.

Kali Linux disables SSH by default because it is designed for stealth during penetration testing. In this step, you will enable the SSH server on Kali and make your first remote connection from Windows using a password.

In this step, get ready to:
  • Enable and start the SSH server on your Kali VM.
  • Verify the built-in SSH client on Windows.
  • Make your first SSH connection from Windows to Kali.
Enable the SSH server on your Kali VM

Your Kali VM has the SSH server software installed, but the service is stopped and disabled. You need to update your packages, start the service, and tell it to run automatically on every boot.

  • Open a terminal on your Kali VM.
  • Update your package lists and upgrade installed packages by running:
sudo apt update && sudo apt upgrade -y

This may take a minute. You will see packages being fetched and unpacked in the terminal output.

  • Install the OpenSSH server package by running:
sudo apt install openssh-server -y

Seeing a network error?

If apt cannot reach the package servers, your VM may not have internet access. Check that your VM's network adapter is set to NAT or Bridged Adapter in your hypervisor's settings, then retry the command.

help me fix network connectivity on my Kali VM so apt can reach package servers

  • Start the SSH service and enable it to run on boot by running these two commands:
sudo systemctl start ssh
sudo systemctl enable ssh
  • Verify the service is running by running:
sudo systemctl status ssh

You should see a line that says active (running) in green text. This confirms SSH is ready to accept connections.

What is systemd?

Systemd is the service manager on modern Linux systems. It controls which programs start on boot, keeps them running, and lets you check their status. The systemctl command is how you interact with it.

  • Press q to exit the status view.
  • Find your Kali VM's IP address by running:
hostname -I

You will see one or more IP addresses printed. Note down the first one (it will look something like 192.168.1.105). You will use this to connect from Windows.

Which IP address to use

If you see multiple addresses, use the one that starts with 192.168 or 10.0. These are local network addresses that your Windows machine can reach.

No IP address shown?

If hostname -I returns nothing, your VM has no network connection. In your hypervisor (VirtualBox or VMware), check that the VM's network adapter is enabled and set to Bridged Adapter or Host-only Adapter. Then restart the VM and try again.

help me configure my Kali VM network adapter so it gets an IP address

Verify the SSH client on Windows

Windows 11 ships with an OpenSSH client built in. You do not need to install anything. Let's confirm it works.

  • Press the Windows key to open your search bar.
  • Type PowerShell and press Enter to open it.
  • Verify the SSH client is available by running:
ssh -V

You should see a version string printed, confirming the client is ready.

Why is this already installed?

Microsoft bundles the OpenSSH client with Windows 10 and 11. Commands like ssh, ssh-keygen, and scp all work directly from PowerShell with no extra setup.

Make your first SSH connection to Kali

Your Kali VM is listening for SSH connections and your Windows machine has the client ready. Time to connect the two. For your Windows machine to reach the VM, both need to be on the same local network.

VM networking requirement

Your VM's network adapter must be set to Bridged Adapter or Host-only Adapter in your hypervisor (VirtualBox or VMware). NAT mode also works if you configure port forwarding, but bridged is the simplest option for this project.

Before you run the next command, think about what will happen. This is the first time your Windows machine has ever contacted your Kali VM over SSH. Do you think it will connect immediately, or will something else happen first?

  • In PowerShell, connect to your Kali VM by running:
ssh kali@[[VM_IP="your Kali VM's IP address"]]

Because this is the first time you are connecting to this server, SSH shows a host key fingerprint and asks you to verify it. You will see a message like this:

The authenticity of host '192.168.x.x (192.168.x.x)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

What is a host key fingerprint?

A host key is the server's unique cryptographic identity. The first time you connect, SSH asks you to confirm you trust this server. Once you type yes, the fingerprint is saved to your known_hosts file and you will not be asked again for this server.

  • Type yes and press Enter to accept the fingerprint.
  • When prompted for a password, type your Kali user password and press Enter.

Default Kali credentials

If you are using a pre-built Kali VM image, the default username is kali and the default password is kali. If you set your own credentials during installation, use those instead. The password will not show any characters as you type.

After entering your password, you should land at the Kali shell prompt. It looks like this:

┌──(kali㉿kali)-[~]
└─$

You are now controlling your Kali VM remotely from Windows. Every command you type in this session runs on the Kali machine, not on your Windows machine.

Connection refused or timed out?

If you see Connection refused, the SSH service is not running on Kali. Switch back to your Kali VM terminal and run sudo systemctl start ssh again.

If the connection times out, your Windows machine cannot reach the VM's IP. Verify both machines are on the same network by checking that the IP addresses share the same first three number groups (e.g., both start with 192.168.1).

help me troubleshoot my SSH connection from Windows to my Kali VM

You now have a working remote connection to your Kali server from Windows. Anyone who knows your password could do the same thing. In the next step, you will look at what the server records about every login attempt and see why password-only access is a risk.

Expose the Weakness

Your SSH connection from Step 1 works. You can reach your Kali VM from Windows and log in with a password. But that's exactly the problem.

Right now, anyone who can reach your VM's IP address could try guessing your password. In this step, you'll see exactly what your server records about login attempts. This is what an attacker's reconnaissance looks like from the defender's side.

In this step, get ready to:
  • Generate a deliberate failed login attempt from Windows.
  • View SSH authentication logs on Kali to see what the server recorded.
  • Understand why password-based SSH is vulnerable to brute-force attacks.
Generate failed and successful login attempts

To understand your server's vulnerability, you need to create some test data. You'll generate both a failed and a successful login so the logs have something interesting to show.

  • Switch back to your PowerShell window on Windows.
  • If you're still connected to Kali via SSH from the previous step, type exit and press Enter to return to PowerShell.
  • Attempt to SSH into your Kali VM with a fake username by running this command:
ssh notauser@[[VMIP="your Kali VM's IP address"]]
  • When prompted for a password, type anything (like test) and press Enter.
  • Repeat for each password prompt until the connection closes on its own.

You'll see a message saying permission was denied. That's exactly what you want. Your server just recorded this failed attempt.

  • Now generate a successful login by connecting with your real credentials:
ssh kali@[[VMIP="your Kali VM's IP address"]]
  • Enter your Kali password when prompted.

You should land at a shell prompt on Kali. You now have both a failed and successful login recorded in the server's logs.

Connection timed out or refused?

Make sure your Kali VM is still running and the SSH service is active. Switch to your Kali VM terminal and run sudo systemctl status ssh to confirm it shows active (running).

If you changed your VM's network settings since Step 1, your IP address may have changed. Run hostname -I on Kali to check.

help me troubleshoot my SSH connection to Kali

View SSH authentication logs

Your server has been quietly recording every login attempt. The journalctl command reads these logs from systemd's journal. You can filter by service name to see only SSH events.

Before you check the logs, think about this: what information do you expect the server recorded about your two login attempts?

  • View the last 20 SSH log entries by running this command:
sudo journalctl -u ssh -n 20

You should see entries for both your attempts. Look for two key patterns in the output.

What do these log entries mean?

  • A failed login appears as: Failed password for invalid user notauser from <IP> port <port> ssh2. This tells you the username tried, the source IP, and the port.
  • A successful login appears as: Accepted password for kali from <IP> port <port> ssh2. Same details, but confirmation that the login succeeded.
  • Every entry has a timestamp showing exactly when the attempt happened.
  • Find both entries in your output and confirm you can identify the timestamp, username, and source IP for each one.

Not seeing any log entries?

Make sure you included sudo before the command. Without it, you may not have permission to read the journal.

If you see "No entries" or very old entries, double check the service name. On Kali, the SSH service is called ssh (not sshd).

help me troubleshoot why journalctl shows no SSH entries

Understand why password-based SSH is dangerous

You just generated one failed login attempt. On a public-facing server, automated bots attempt thousands of passwords per hour against every SSH server they find.

What does brute-force look like in production?

Bots scan the internet for open port 22. When they find one, they cycle through common username and password combinations at high speed. Your logs would fill with hundreds of "Failed password" entries per minute.

Your only protection right now is password strength. If your password is weak or common, a bot will eventually guess it. The server happily accepts any correct password, no matter who typed it.

The next step eliminates this entire attack surface. Key-based authentication is cryptographically unguessable. No password means nothing to brute-force.

Your server is faithfully recording every attempt. Now you know exactly what you're defending against. Next, you'll replace passwords with cryptographic keys that make brute-force attacks impossible.

Lock Down with SSH Keys

In the previous step, you watched your server record every login attempt in real time. You saw exactly what an attacker would target.

The problem is clear: anyone who can reach your VM can try to guess your password. SSH keys replace guessable passwords with cryptographic proof. Once you switch to keys and disable password login, brute-force attacks become mathematically impossible.

In this step, get ready to:
  • Generate an Ed25519 SSH key pair on your Windows machine.
  • Copy your public key to the Kali VM and test key-based login.
  • Disable password authentication and verify the lockdown.
Generate and deploy your SSH key pair

An SSH key pair consists of two files: a private key (your secret, stays on Windows) and a public key (shared with servers you want to access). The server checks whether the connecting client holds the matching private key.

  • Switch back to your PowerShell window on Windows.
  • Generate your Ed25519 key pair by running this command:
ssh-keygen -t ed25519

What will ssh-keygen ask you?

The command prompts you for three things:

  • File location: press Enter to accept the default path.
  • Passphrase: press Enter for no passphrase (fine for a lab environment).
  • Confirm passphrase: press Enter again.
  • Press Enter at each prompt to accept defaults (no passphrase).

You should see output confirming your key was saved to C:\Users\<your-username>\.ssh\id_ed25519 with a randomart image displayed.

Seeing 'file already exists' warning?

If you have a previous key at that path, ssh-keygen asks whether to overwrite. Type y and press Enter to replace it. The old key will no longer work for any servers that used it.

help me troubleshoot ssh-keygen overwrite warnings on Windows

Now you need to get your public key onto the Kali VM. Windows does not include ssh-copy-id, so you will pipe the key through SSH directly.

  • Copy your public key to the Kali VM by running this command:
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh kali@[[VM_IP="your Kali VM's IP address"]] "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh"

What does this command do?

  • type $env:USERPROFILE\.ssh\id_ed25519.pub reads your public key file on Windows.
  • The pipe (|) sends that content to the SSH session on your Kali VM.
  • mkdir -p ~/.ssh creates the SSH directory if it does not exist.
  • cat >> ~/.ssh/authorized_keys appends your public key to the authorized keys file.
  • chmod 600 and chmod 700 set strict permissions that SSH requires.
  • When prompted, enter your Kali password one last time to authenticate the copy.

The command completes silently. Your public key is now on the server.

Permission denied or connection refused?

Double-check that you are using the correct IP address for your Kali VM. You can verify by running hostname -I on the Kali terminal.

help me fix a permission denied error when copying my SSH key to my Kali VM

Test key-based login and disable passwords

Your public key is deployed. Before disabling passwords, you need to confirm that key-based login actually works. If you disable passwords first and the key is misconfigured, you will lock yourself out.

  • Test your key-based login by running this command from PowerShell:
ssh kali@[[VM_IP="your Kali VM's IP address"]]

You should connect directly to a shell prompt on Kali without being asked for a password. This confirms your key pair is working.

Still being asked for a password?

This means the key was not copied correctly or the permissions are wrong. SSH into Kali with your password and check:

  • Run ls -la ~/.ssh/ and confirm the directory is drwx------ (700).
  • Run ls -la ~/.ssh/authorized_keys and confirm the file is -rw------- (600).
  • Run cat ~/.ssh/authorized_keys and confirm you see a line starting with ssh-ed25519.

help me fix key-based SSH login not working to my Kali VM

  • Type exit to disconnect from the SSH session and return to your Windows PowerShell.

Key login works. Now it is time to disable password authentication entirely. You will edit the SSH server configuration on Kali.

  • Switch to your Kali VM terminal.
  • Open the SSH configuration file by running:
sudo nano /etc/ssh/sshd_config
  • Press Ctrl+W to open the search bar in nano.
  • Type PasswordAuthentication and press Enter to jump to the line.
  • Find this commented line:
#PasswordAuthentication yes
  • Replace that entire line with:
PasswordAuthentication no

Why remove the # and change to no?

Lines starting with # are comments and have no effect. By removing the # and setting the value to no, you tell the SSH server to reject all password-based login attempts. Only clients with a matching private key can connect.

  • Save the file by pressing Ctrl+O, then press Enter to confirm.
  • Exit nano by pressing Ctrl+X.
  • Restart the SSH service to apply the change by running:
sudo systemctl restart ssh

The SSH server now rejects password logins. Only your private key will get you in.

Verify the lockdown

This is the moment of truth. You need to confirm two things: that passwords are truly rejected, and that your key still lets you in.

Before you run the next command, predict what will happen: if you force SSH to use only password authentication (no key), do you think the server will let you in or reject you?

  • Switch back to your PowerShell window on Windows.
  • Attempt a password-only connection by running:
ssh -o PubkeyAuthentication=no kali@[[VM_IP="your Kali VM's IP address"]]

You should see Permission denied (publickey). immediately. No password prompt appears at all. This proves that password authentication is completely disabled.

What does -o PubkeyAuthentication=no do?

The -o flag overrides SSH client settings for this one connection. By disabling public key authentication on the client side, you force SSH to try password login instead. Since the server no longer accepts passwords, the connection is immediately rejected.

  • Now confirm your key still works by running a normal connection:
ssh kali@[[VM_IP="your Kali VM's IP address"]]

You land at a Kali shell prompt with no password prompt. Your key-based authentication is working perfectly.

Getting Permission denied on both commands?

If even your normal SSH connection fails, your key setup has an issue. Switch to the Kali VM terminal directly (not via SSH) and check:

  • Verify that /home/kali/.ssh/authorized_keys contains your public key.
  • Verify permissions with ls -la ~/.ssh/ (directory must be 700, file must be 600).
  • If needed, temporarily re-enable passwords by editing /etc/ssh/sshd_config back to PasswordAuthentication yes, restart SSH, fix the key issue, then disable passwords again.

help me recover from being locked out of SSH on my Kali VM

Your server now rejects anyone who does not hold your private key. Brute-force password attacks are impossible. Next up, you will add a firewall to block all network traffic except SSH.

Set Up the Firewall with UFW

Your SSH connection is now locked down with key-only authentication. No one can brute-force their way in with passwords anymore. But your server might still have other doors open.

Any network service you accidentally start becomes an attack surface if nothing is blocking incoming traffic. In this step, you'll install and configure UFW (Uncomplicated Firewall) to ensure only SSH traffic gets through to your Kali VM.

In this step, get ready to:
  • Install UFW and add a rule allowing SSH traffic.
  • Set default firewall policies and enable UFW.
  • Verify the firewall blocks everything except SSH.
Install UFW and allow SSH traffic

UFW is not pre-installed on Kali Linux. You need to install it first, then immediately add a rule to allow SSH connections before you turn the firewall on.

Critical safety step

You MUST allow SSH through the firewall before enabling it. If you enable UFW without an SSH rule, you will be locked out of your own remote session with no way back in except through the VM console directly.

  • On your Kali VM terminal, install UFW by running this command:
sudo apt install ufw -y

You should see package installation output ending with a confirmation that UFW was installed successfully.

  • Add a rule to allow SSH traffic through the firewall by running:
sudo ufw allow ssh

You should see output confirming the rules were updated for both IPv4 and IPv6.

Why allow SSH before enabling?

UFW flushes all its chains when you enable it. If there is no SSH allow rule in place at that moment, the default deny policy takes effect immediately and your remote connection drops.

Adding the rule first ensures SSH survives the transition.

Package not found?

If apt cannot find the UFW package, your package list may be outdated. Run sudo apt update first, then retry the install command.

Help me troubleshoot this

Set default policies and enable the firewall

With the SSH rule in place as your safety net, you can now configure the default policies and turn UFW on.

  • Set the default policy to deny all incoming traffic by running:
sudo ufw default deny incoming
  • Set the default policy to allow all outgoing traffic by running:
sudo ufw default allow outgoing

Each command confirms the default policy was changed.

What do these policies mean?

Deny incoming means any connection attempt from outside is blocked unless you have added a specific rule to allow it. Your SSH allow rule is that specific exception.

Allow outgoing means your server can still reach the internet for updates, DNS lookups, and package downloads. Outbound traffic is rarely the attack vector on a server.

  • Enable the firewall by running:
sudo ufw enable

What happens when you run this?

UFW will show a confirmation prompt warning that the command may disrupt existing SSH connections. Type y and press Enter to confirm. Because you already added the SSH allow rule, your connection will stay alive.

You should see a message confirming the firewall is active and enabled on system startup.

  • Verify your SSH connection still works. Switch to your Windows PowerShell and connect to your Kali VM:
ssh kali@[[VM_IP="your Kali VM IP address"]]

You should land at your Kali shell prompt just as before. The firewall is letting SSH through.

SSH connection timed out?

If your SSH connection hangs or times out, you may have enabled UFW without the SSH allow rule. Access your Kali VM directly through the VM console (not SSH), then run sudo ufw disable to turn off the firewall. Start this substep again from the beginning.

Help me recover SSH access

Verify the firewall rules

The firewall is active. Now confirm it is configured exactly as intended by checking the status and seeing what ports are actually accessible.

  • Before you run the next command, predict what you expect to see. What ports should be allowed? What should the default policies show?
  • Check the full firewall status by running:
sudo ufw status verbose

You should see output showing the firewall is active, with default deny for incoming traffic, default allow for outgoing traffic, and port 22 (SSH) allowed from anywhere.

  • Check which ports are actively listening on your server by running:
sudo ss -tlnp

You should see port 22 listed as listening (your SSH server). Even if other services happen to be running, the firewall blocks external access to anything except SSH.

What does ss -tlnp show?

The ss command shows socket statistics. The flags mean: -t for TCP connections, -l for listening sockets only, -n for numeric port numbers (not service names), and -p to show the process using each port.

Your server now has a proper perimeter. Only SSH traffic on port 22 can reach your Kali VM from the outside. Everything else is silently dropped. Next up, you'll set up live log monitoring so you can watch every login attempt happen in real time.

Monitor Login Attempts

Your server is locked down with key-only authentication and a firewall blocking everything except SSH. But a hardened server is only as secure as your ability to see who is knocking on the door.

Real-time log monitoring lets you detect suspicious activity the moment it happens. In this step, you will watch SSH events stream across your terminal live, filter for failed logins, and build the habit of checking who has been trying to connect.

In this step, get ready to:
  • Start a live log stream filtering for SSH events and watch a failed login appear in real time.
  • Use journalctl filtering to isolate only failed login events.
  • Explore login history and time-based log filters.
Start a live log stream and generate a test event

Linux records every SSH connection attempt in its system journal. You can tail this journal in real time, similar to watching a security camera feed.

  • In your Kali VM terminal, start a live SSH log stream by running this command:
sudo journalctl -u ssh -f

What does this command do?

The -u ssh flag filters the journal to only the SSH service.

The -f flag means "follow". It keeps the stream open and prints new log entries as they happen, like a live feed.

Your terminal is now waiting for SSH events. It will print new lines as connections arrive.

  • Leave this terminal running. Switch to your Windows machine and open PowerShell.
  • Generate a failed login attempt by running this command (using a fake username that does not exist on Kali):
ssh fakeuser@[[KALI_IP="your Kali VM IP address"]]
  • You will see a Permission denied error. That is expected. The point is to generate a log entry on Kali.
  • Switch back to your Kali terminal where the live stream is running.

What do you expect to see in the log stream? Take a moment to predict before you look.

You should see a line appear that includes the words Invalid user fakeuser along with the source IP address of your Windows machine. This proves the server records every connection attempt in real time.

Not seeing the log entry?

  • Make sure your journalctl stream is still running. If you accidentally pressed Ctrl+C, restart it with sudo journalctl -u ssh -f.
  • Confirm you used the correct Kali VM IP address in your SSH command from Windows.
  • If the stream shows nothing at all, try generating a successful login from another PowerShell window using ssh kali@<your-kali-ip> to confirm the stream is working.

Why isn't my journalctl live stream showing SSH events?

Filter logs to isolate failed login events

A live stream shows everything. On a busy server, you need to narrow down to just the events that matter. journalctl has a built-in --grep flag that filters entries by pattern, similar to piping through grep but more efficient.

  • Press Ctrl+C in your Kali terminal to stop the live stream.
  • Filter the SSH logs for failed events only by running:
sudo journalctl -u ssh --grep="Failed"

You should see entries that include the pattern Failed password for or Invalid user from your earlier test attempts across this project.

What does --grep do?

The --grep flag filters entries where the message field matches a Perl-compatible regular expression. If your pattern is all lowercase, the match is case-insensitive. Otherwise it is case-sensitive.

This is preferred over piping journalctl | grep because it avoids journalctl doing unnecessary work loading entries that will just be discarded.

  • Now count how many failed events exist in the log by piping to wc -l:
sudo journalctl -u ssh --grep="Failed" --no-pager | wc -l

You will see a number representing the total failed SSH attempts recorded on this server. On a public-facing server, this number could be in the thousands per day.

Seeing zero results?

  • If you completed Step 2 (Expose the Weakness) before password authentication was disabled, your failed attempts from that step may use the exact pattern Failed password. Try sudo journalctl -u ssh --grep="Invalid|Failed" to catch both patterns.
  • Confirm you are running the command with sudo. Without it, you may not have permission to read all journal entries.

Why is my journalctl grep returning no results?

Check login history and use time filters

Beyond the journal, Linux keeps a separate record of who has successfully logged in. The last command reads this record and shows you recent sessions.

  • View recent login history by running:
last

You will see a table showing usernames, source IPs, login times, and session durations for every recent login. This is useful for quickly checking who has accessed the server.

  • Now use a time filter to view only SSH journal events from the last hour by running:
sudo journalctl -u ssh --since "1 hour ago"

What time formats does --since accept?

The --since flag accepts several formats. You can use keywords like yesterday or today, relative times like "1 hour ago", or exact timestamps like "2026-07-24 14:00:00".

You can combine --since with --until to define a specific time window. For example, --since "today" --until "now" shows everything from midnight up to this moment.

You should see all SSH-related log entries from the past hour, including your successful key-based logins and your failed test attempt from earlier.

Before you run the final verification, what do you think you will see in a live stream if you generate another failed login right now?

  • Restart the live log stream on Kali by running:
sudo journalctl -u ssh -f
  • Switch to PowerShell on Windows and generate another failed login:
ssh nobody@[[KALI_IP="your Kali VM IP address"]]

Watch your Kali terminal. You should see the failed attempt appear instantly in the log stream, showing the username, source IP, and timestamp. This is your real-time intrusion detection in action.

Stream not updating?

  • If you see Connection refused from Windows, your SSH service may have stopped. Run sudo systemctl status ssh on Kali to check.
  • If the firewall is blocking your connection, verify with sudo ufw status that port 22 is still allowed.

Why is my live journalctl stream not showing new SSH events?

Secret mission

Custom Port and Rate Limiting

Your server is locked down with keys and a firewall, but it still listens on port 22. Every automated scanner on the internet hammers port 22 first. In this mission, you will move SSH to a non-standard port and add rate limiting to throttle anyone who tries to brute-force their way in.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on your local Kali VM and Windows machine, so there are no ongoing cloud costs.

Resources you used:

  • SSH key pair on Windows (id_ed25519 and id_ed25519.pub in C:\Users\<user>\.ssh\).
  • SSH server configuration changes on Kali (/etc/ssh/sshd_config modified to use port 2222 and key-only auth).
  • Authorized keys file on Kali (/home/kali/.ssh/authorized_keys).
  • UFW firewall installed and configured on Kali with rate-limiting rules.
  • Known hosts entry on Windows (C:\Users\<user>\.ssh\known_hosts).

Keep everything running

No action needed. Choose this if you plan to keep practicing with your hardened server or want to build on this setup for future security projects.

  • Your SSH server continues running on port 2222 with key-only authentication.
  • Your UFW firewall stays active, blocking all traffic except rate-limited SSH.
  • Your SSH keys remain stored on your Windows machine for future connections.

Pause - I'll come back to this later

Shut down the SSH service and disable the firewall to free up resources. Your configuration files and keys stay intact so you can resume later.

  • On your Kali VM, stop and disable the SSH service by running:
sudo systemctl stop ssh
sudo systemctl disable ssh
  • Disable the UFW firewall by running:
sudo ufw disable

When you are ready to resume, re-enable both services:

sudo systemctl start ssh
sudo systemctl enable ssh
sudo ufw enable
  • Your SSH keys on Windows and configuration files on Kali remain untouched.

Delete - I don't want to use this again

Remove all project resources and revert your systems to their pre-project state.

On your Windows machine, open PowerShell and remove your SSH key pair:

Remove-Item -Path "$env:USERPROFILE\.ssh\id_ed25519" -Force
Remove-Item -Path "$env:USERPROFILE\.ssh\id_ed25519.pub" -Force
  • Remove the Kali VM entry from your known hosts file:
Remove-Item -Path "$env:USERPROFILE\.ssh\known_hosts" -Force

Other entries in known_hosts

If you have connected to other servers before, your known_hosts file may contain other entries you want to keep. In that case, open the file in a text editor and delete only the line containing your Kali VM's IP address instead of removing the entire file.

On your Kali VM, remove the authorized keys and revert SSH configuration:

rm /home/kali/.ssh/authorized_keys
  • Revert your SSH configuration to defaults. Open the config file:
sudo nano /etc/ssh/sshd_config
  • Change Port 2222 back to Port 22 (or comment out the line with # to use the default).
  • Change PasswordAuthentication no back to PasswordAuthentication yes.
  • Save the file and exit the editor.
  • Reset UFW to remove all rules and disable the firewall:
sudo ufw reset
  • Remove UFW from your system:
sudo apt remove ufw -y
  • Stop and disable the SSH service:
sudo systemctl stop ssh
sudo systemctl disable ssh

Your Kali VM is now back to its pre-project state with no SSH server running, no firewall, and no authorized keys.

Nice Work!

Nice Work!

You just hardened a Linux server from scratch. Your Kali VM now rejects password guesses, blocks unauthorized traffic, and logs every knock on the door in real time.

You've learned how to:

  • Enable and configure SSH on a Linux server and connect remotely from Windows using PowerShell.
  • Generate an Ed25519 key pair and enforce key-only authentication, eliminating brute-force risk entirely.
  • Install and configure UFW to block all incoming traffic except SSH, and monitor login attempts in real time with journalctl.
  • Secret Mission: Move SSH to a non-standard port and add UFW rate limiting to throttle brute-force attempts.

Ready to quiz yourself?