Introduction
Kali Linux is a Linux distribution for security testing. This course starts with the everyday terminal skills you need before using security tools. You do not need previous Linux or Docker experience.
Your LabEx machine runs Ubuntu and hosts a separate Kali container. A container provides its own files and programs while sharing the host's Linux kernel. The lab prepares this environment for you; you will enter Kali as an ordinary user, identify the system, read command help, and save a small environment record. There is no scan target in this first lab.
Use the Terminal interface throughout this lab. You do not need a desktop, a Docker Hub account, or a software installation step.
Enter Kali and Write Your First File
In this step, you will enter the prepared Kali environment, identify your user and working directory, and write a short text file.
The terminal is the text window; the shell is the program that reads your commands. Click in the Terminal, type a command, and press Enter. Copy only the command, not the prompt printed before it.
The initial terminal belongs to the Ubuntu host as labex. The lab supplies a command named kali that opens a Bash shell in the prepared container. Container setup is already complete; you do not need to run Docker commands yourself.
kali
Your prompt now looks like this:
kali@kali-training:/home/labex/project$
Here kali is your username, kali-training names this container, and the path is your current directory. The final $ conventionally indicates an ordinary user; a root administrator prompt often uses #. Prompts can be customized, so confirm identity with whoami, which prints the effective username:
whoami
Expected output:
kali
You are working as an ordinary user rather than root. Administrative operations are introduced later in the course.
Use pwd (print working directory) to find where files with relative names will be written:
pwd
Expected output:
/home/labex/project
A path beginning with / is an absolute address. This project directory is shared with the Ubuntu host at the same path, so files you save here remain accessible to LabEx. Other container paths, such as /etc/os-release, belong to Kali. The container user's home directory is /home/kali; it is different from the shared project directory.
echo prints a message. Single quotes keep the words together as literal text. The shell's > operator sends output to a file instead of the screen, creating that file or replacing its existing contents. Use it to create your first practice file:
echo 'Kali practice started' > welcome.txt
No output is expected: the message went into welcome.txt in your current directory. cat reads a file and prints its contents:
cat welcome.txt
Expected output:
Kali practice started
This confirms that you can create and read a file in the Kali workspace. Stay in this Kali shell for the next step. If you close the terminal, open a new Terminal and run kali again. Typing exit inside Kali returns to the host; it does not delete the container or your project files.
Identify Kali and Save Its Release Information
In this step, you will read Kali's system identification, use built-in command help, and save a release record without assuming a particular version number.
Linux distributions provide /etc/os-release as a text file of KEY=value entries. /etc holds system configuration and identification files. Read the file inside the Kali shell you opened in Step 1:
cat /etc/os-release
Look for these entries among the output:
PRETTY_NAME="Kali GNU/Linux Rolling"
...
ID=kali
...
ID identifies the distribution; PRETTY_NAME is its human-readable name. Entries beginning with VERSION describe the release when provided, such as VERSION_ID, VERSION, or VERSION_CODENAME. The accepted lab image currently includes these fields, but Linux distributions do not all provide the same version fields. Read the values you actually see instead of copying a version from a tutorial. If ID says ubuntu, you are still on the host: run kali, then repeat the command.
Kali is a rolling distribution, so its software changes over time. This lab uses a fixed image to keep the exercise reproducible. You do not need to update or upgrade software to identify the environment. A minimal Kali container also does not contain every security tool.
To learn how a command works, many programs provide a --help option. An option changes the requested behavior; --help asks for usage information rather than reading a file. Try it with cat:
cat --help
Near the start, you should see:
Usage: cat [OPTION]... [FILE]...
Concatenate FILE(s) to standard output.
[FILE] is a placeholder for file paths, not text to type literally. Optional parts appear in square brackets. The help confirms that the file contents normally go to standard output, which you have been reading on the terminal.
Reuse > from Step 1 to save that output. This time, the command produces the actual release information rather than a message you typed:
cat /etc/os-release > kali-release.txt
This reads /etc/os-release and writes a separate file in your project directory. It does not change the system identification file. Read your saved record:
cat kali-release.txt
The output should match the source you read earlier, including ID=kali and all available VERSION entries. Keeping the complete small file preserves the original values and quoting without requiring filtering commands you have not learned yet. You now have a readable environment record in /home/labex/project/kali-release.txt.
Summary
You entered a prepared Kali container from the Ubuntu host, recognized the ordinary-user prompt, and confirmed your identity and working directory. You created and read a text file, used cat --help, and saved Kali's actual release information in the shared workspace.
In the paired challenge, you will use the same skills to produce an accurate release record in a fresh, independent environment.
