DEV Community: Yeasin's

File and Directory Management in Linux

Yeasin's — Sun, 25 Oct 2026 02:25:11 +0000

Everything in Linux is a file. Your documents are files, your programs are files, your terminal is a file, even your hardware devices are represented as files. This single idea is what makes Linux so powerful and consistent — but it also means that if you want to be productive on the command line, you must learn to manage files and directories fluently.

In this guide, we'll cover the essential commands and concepts: navigating the filesystem, creating, copying, moving, and deleting files, understanding the directory structure, finding files fast, and — critically — how to avoid the mistakes that destroy data.

The Linux Directory Structure: Start Here

Before touching any command, you need a map. Unlike Windows with its C:\ drive, Linux has one single tree that starts at the root directory, written as /.

ls /

bin   dev  home  lib32  media  opt   root  sbin  srv  tmp  var
boot  etc  lib   lib64  mnt    proc  run   snap  sys  usr

The important ones to know:

Directory	What lives here
`/home`	Personal folders of normal users (`/home/yeasin`)
`/root`	Home directory of the root user
`/etc`	System-wide configuration files
`/var`	Variable data: logs (`/var/log`), caches, websites
`/tmp`	Temporary files — often cleared on reboot
`/usr`	Installed programs and their files
`/opt`	Third-party / manually installed software
`/dev`	Device files (disks, terminals appear here)
`/proc`	Virtual files exposing kernel and process info

Note: Unlike Windows, Linux uses / (forward slash) as the separator, and paths are case-sensitive. /home/Yeasin and /home/yeasin are two different paths.

Absolute vs relative paths

There are two ways to write a path:

Absolute path — starts from /: /home/yeasin/projects/app.js (works from anywhere)
Relative path — starts from your current location: projects/app.js

Two special names help you move around:

. — the current directory
.. — the parent directory (one level up)

So cd .. moves up, and cd ../.. moves up two levels.

Navigating: pwd, ls, and cd

Always know where you are before you act. Three commands handle all navigation:

Where am I? — `pwd`

pwd

/home/yeasin

pwd (print working directory) shows your current location in the tree. It sounds trivial, but in long terminal sessions with multiple tabs, it saves you from running commands in the wrong place.

What's here? — `ls`

ls            # list names only
ls -l         # long format: permissions, owner, size, date
ls -a         # include hidden files (starting with .)
ls -la        # long + hidden, the everyday combo
ls -lh        # long + human-readable sizes (K, M, G)
ls -lt        # sorted by modification time, newest first

Example output:

total 24K
drwxr-xr-x 3 yeasin yeasin 4.0K Oct 17 12:00 projects
-rw-r--r-- 1 yeasin yeasin 2.2K Oct 16 18:42 notes.txt
drwxr-xr-x 2 yeasin yeasin 4.0K Oct 15 09:10 .ssh

Two useful extras: ls -R lists directories recursively, and ls /etc lists a directory without entering it.

Moving around — `cd`

cd /var/log        # go to an absolute path
cd projects        # go into a subdirectory (relative)
cd ..              # go up one level
cd ~               # go to your home directory
cd -               # go back to the previous directory
cd                 # no argument = home directory too

cd - is a small trick worth remembering: it toggles between your last two locations, like a channel-swap button.

Creating Files and Directories

Touch — create an empty file

touch notes.txt
touch a.txt b.txt c.txt

touch also has a second job: it updates the timestamp of an existing file without changing its content.

mkdir — create directories

mkdir projects
mkdir projects/src projects/docs    # multiple at once
mkdir -p projects/src/components    # create parents as needed

The -p flag is the one to remember. Without it, creating projects/src/components fails if projects doesn't exist yet. With -p, the whole chain is created in one shot.

Creating files with content

For a quick file with text, you don't even need an editor:

echo "Hello, world" > hello.txt      # overwrite
echo "Second line" >> hello.txt      # append

Copying and Moving

cp — copy

cp notes.txt backup.txt             # copy a file
cp -r projects projects-backup      # copy a directory (recursive required)
cp -i notes.txt old.txt            # ask before overwriting
cp *.txt /tmp/                      # copy all .txt files somewhere

Warning: cp overwrites existing files silently by default. If old.txt already exists, it's gone with no confirmation. Use -i (interactive) whenever you're unsure. A safer habit for a session: alias cp='cp -i'.

Note that cp for a directory requires -r — without it, cp refuses to copy directories. This is a safety feature, not a limitation.

mv — move and rename

mv is two commands in one — it moves files and it renames them (renaming is moving to a new name):

mv notes.txt documents/        # move into a directory
mv notes.txt todo.txt          # rename
mv -i old.txt documents/      # ask before overwriting
mv projects/ archive/         # move a whole directory

mv is fast even for huge files, because moving on the same filesystem doesn't copy data — it just updates the pointer.

Deleting: rm, rmdir, and Staying Safe

This is the part where mistakes hurt, so let's be careful and precise.

rm — delete files

rm notes.txt          # delete one file — no recycle bin, no undo
rm -i notes.txt       # ask for confirmation first
rm -r projects        # delete a directory and everything inside
rm -f stuck.txt      # force: ignore warnings, don't ask

Three facts every Linux user must internalize:

There is no trash bin. rm is permanent.
rm -r is powerful enough to delete an entire system. That's why sudo rm -rf / is the most infamous command in Linux — it means "delete everything, don't ask, no exceptions."
rm doesn't ask for confirmation by default. A typo in a path can delete the wrong thing instantly.

rmdir — the cautious alternative

rmdir empty-folder

rmdir only removes empty directories. If there's anything inside, it refuses. This makes it a great "safe" option when you expect a folder to be empty and want to be alerted if it's not.

Safer deletion patterns

A professional habit: list first, then delete.

ls projects/*.log    # see exactly what will be deleted
rm projects/*.log    # now delete it

Even better — use -i once and build the habit:

rm -ri old-projects/

Tip: One character in the wrong place makes rm dangerous. rm -rf projects / (with a space before the slash) would delete projects and the root filesystem. This is not a joke command — it's a real typo people have made. Always read the full command once before pressing Enter, especially with sudo.

Viewing Files

Before editing, you usually want to look inside a file:

cat notes.txt        # print the whole file
less notes.txt      # open in a pager: q to quit, / to search
head -n 20 notes.txt  # first 20 lines
tail -n 20 notes.txt  # last 20 lines
tail -f app.log      # follow a log file live as it grows

The distinction matters for real work:

cat is fine for small files, but a 10,000-line log will flood your terminal.
less lets you scroll, search (/pattern), and quit with q.
tail -f is how sysadmins watch logs in real time — every new line appears as it's written. Debugging a live service? This is your window.

Finding Files: find and locate

find — powerful, real-time search

find /var/log -name "*.log"             # by name
find ~ -type d -name projects            # directories only
find /etc -iname "*.conf"                # case-insensitive
find . -size +100M                       # files bigger than 100 MB
find . -mtime -7                        # modified in the last 7 days
find . -name "*.tmp" -delete             # find AND delete in one command

find walks the actual filesystem, so it's always accurate — but can be slow on huge trees. The -delete action at the end is efficient, but treat it like rm: run the command without -delete first to preview the results.

locate — fast, database-based

sudo apt install plocate -y
locate nginx.conf

locate answers instantly because it searches a pre-built database (updated daily, or manually with sudo updatedb). The tradeoff: very new files may not be in the database yet.

Wildcards: The Pattern Language of the Shell

Wildcards (glob patterns) are how you select many files at once — and they work with every command:

Pattern	Matches
`*`	Any number of any characters
`?`	Exactly one character
`[abc]`	One character: a, b, or c
`*.txt`	All files ending in `.txt`
`file?.log`	`file1.log`, `fileA.log` — but not `file10.log`

Real examples:

cp *.jpg /backup/
rm old-*.tmp
mv report?.pdf reports/

Note: The shell expands the wildcard before the command runs — the command never sees the *, only the expanded list. This is why listing with ls first is a reliable preview of what a glob will touch.

A Practical Workflow: Organizing a Messy Folder

Let's combine everything into a realistic scenario. Your home directory is full of loose files:

ls ~

app.js  index.html  notes.txt  package.json  old-report.pdf  server.js  styles.css

Clean it up in a few commands:

mkdir -p ~/web/{src,docs,reports}          # create the structure in one line
mv *.js *.css *.html ~/web/src/            # move code files
mv notes.txt ~/web/docs/
mv old-report.pdf ~/web/reports/

Then verify:

find ~/web -type f

/home/yeasin/web/src/app.js
/home/yeasin/web/src/server.js
/home/yeasin/web/src/index.html
/home/yeasin/web/src/styles.css
/home/yeasin/web/docs/notes.txt
/home/yeasin/web/reports/old-report.pdf

That {src,docs,reports} syntax is brace expansion — another shell trick worth remembering. mkdir -p a/{one,two,three} creates three subdirectories instantly.

Common Mistakes and Troubleshooting

1. "No such file or directory" — but the file is right there
Linux paths are case-sensitive: Notes.txt is not notes.txt. Use ls and tab completion (press Tab to auto-complete names) to avoid typos entirely.

2. Deleted something you needed
No recycle bin exists, so recovery depends on backups. The lesson: build the list-first habit, and use mv to a "trash" folder instead of rm for anything you might miss:

mkdir ~/.trash
mv important.txt ~/.trash/

3. cp says "omitting directory"
You forgot -r. Directories always need cp -r.

4. Running out of space — finding the culprit

df -h                     # disk usage per filesystem
du -sh /var/* | sort -h   # which folders are big
find ~ -size +500M        # huge files in your home

5. Permission denied
Some files belong to other users or root. Don't reflexively add sudo — first check who owns the file with ls -l, and prefer fixing ownership or location rather than escalating. (chown and chmod deserve their own article — coming next in this series.)

Summary

Linux has one filesystem tree starting at /, with a standard directory layout — learn /home, /etc, /var, and /tmp first.
Navigation is three commands: pwd (where am I), ls (what's here), cd (go there).
Create with touch and mkdir -p; copy with cp -r; move/rename with mv.
rm is permanent — there is no trash bin. List first (ls), then delete, and use -i when unsure.
View files with less, head/tail, and tail -f for live logs.
Find files with find (accurate, real-time) or locate (instant, database-based).
Wildcards (*, ?) work with every command and are expanded by the shell before the command runs.

Master these commands until they're muscle memory, and the command line stops feeling like a struggle — it starts feeling like home. Every sysadmin skill you learn next, from servers to security, builds on this foundation.

SSH and Remote Access Configuration in Linux

Yeasin's — Sat, 17 Oct 2026 15:01:44 +0000

Almost every server in the world is managed remotely. Nobody walks into a data center, plugs in a monitor, and types commands. Instead, administrators connect over the network using SSH (Secure Shell) — the standard, encrypted way to control one computer from another.

If you are learning Linux system administration, this is one of the first real skills you need. In this guide, we will cover what SSH is, how it works under the hood, how to install and configure the SSH server on Debian and Ubuntu, how to set up passwordless login with keys, and — most importantly — how to lock down your server so it is safe on the public internet.

What Is SSH and Why Does It Matter?

SSH is a protocol that gives you a secure, encrypted terminal on a remote machine. When you connect to a server with SSH, it is as if you are sitting in front of it with a keyboard — except you could be on the other side of the world.

Before SSH, people used tools like telnet, which sent everything — including your password — in plain text. Anyone watching the network traffic could read it. SSH was created to fix exactly this problem.

With SSH, everything is encrypted:

Your password and commands
The files you transfer
The entire session traffic

SSH is used for far more than terminals, though. Once you know it, you will use it for:

Administering remote servers (your daily driver)
Securely copying files (scp, rsync, sftp)
Tunneling other traffic through an encrypted channel (port forwarding)
Git operations with remote repositories
Automated deployments from CI/CD pipelines

How SSH Works: The Basic Flow

Before the commands, it helps to understand the mechanics. An SSH connection always has two sides:

SSH client — the machine you are sitting at (your laptop, or even Termux on a phone)
SSH server (sshd) — the remote machine you want to log into

The flow looks like this:

You run ssh user@server-ip on the client.
The client and server perform a key exchange and agree on encryption keys for this session.
The server proves its identity using its host key (stored in /etc/ssh/ on the server).
The client verifies your identity — with a password or, better, a public/private key pair.
An encrypted session opens, and you get a shell on the remote machine.

Note: The first time you connect to any server, SSH asks you to confirm the server's fingerprint. It then saves it to ~/.ssh/known_hosts. From then on, if that fingerprint ever changes, SSH refuses to connect and warns you loudly — that is protection against man-in-the-middle attacks, not a bug.

Step 1: Installing the SSH Server

On a fresh Debian or Ubuntu server, the SSH server is usually already installed. Check its status:

sudo systemctl status ssh

If it is not installed:

sudo apt update
sudo apt install openssh-server -y

Then confirm it is running and enabled at boot:

sudo systemctl enable --now ssh
sudo systemctl status ssh

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
     Active: active (running) since Sat 2026-10-17 09:00:00 UTC

The SSH server listens on port 22 by default. Verify it:

sudo ss -tlnp | grep sshd

LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))

Note on Ubuntu: Since Ubuntu 22.10, the service may be named ssh.socket instead of ssh.service (socket activation). The commands above work either way, but if you ever wonder why sshd is not listed as a running service, that is why.

Step 2: Connecting for the First Time

From your client machine:

ssh yeasin@203.0.113.10

The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256\:xxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
yeasin@203.0.113.10's password:

Enter the password, and you are in. If you can ping the server but the connection is refused, the most common cause is a firewall — which brings us to an important step:

sudo ufw allow ssh

On Debian, ufw may not be installed; install it with sudo apt install ufw. Without this rule, remote SSH traffic never reaches the server.

Step 3: Key-Based Authentication (Do This First)

Passwords can be guessed, reused, or leaked. SSH keys solve this. A key pair consists of:

A private key (~/.ssh/id_ed25519) — never leaves your machine. Never share it, never copy it to a server.
A public key (~/.ssh/id_ed25519.pub) — safe to share; you place it on every server you want to access.

The server can verify you own the private key without you ever sending it. That is the whole trick: the private key proves your identity without ever traveling over the network.

Generate a key pair

On your client machine:

ssh-keygen -t ed25519 -C "yeasin@laptop"

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/yeasin/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/yeasin/.ssh/id_ed25519
Your public key has been saved in /home/yeasin/.ssh/id_ed25519.pub

-t ed25519 — the modern, fast, and secure key type. Prefer it over RSA.
The passphrase protects your private key if your laptop is stolen. Recommended.

Copy the public key to the server

ssh-copy-id yeasin@203.0.113.10

That is it. Log in again and you will not be asked for a password:

ssh yeasin@203.0.113.10

Tip: If ssh-copy-id is unavailable (for example on Termux), do it manually by appending your public key to the server's ~/.ssh/authorized_keys file. Make sure the .ssh directory has permission 700 and the file has 600 — SSH ignores keys if the permissions are too open.

Step 4: Understanding and Configuring sshd

All server-side configuration lives in one file:

/etc/ssh/sshd_config

Before changing anything, create a backup:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

After every change, test your configuration before restarting:

sudo sshd -t

No output means everything is fine. Then apply the changes:

sudo systemctl restart ssh

Warning: Never close your current SSH session while testing new SSH settings. Keep it open, open a second terminal, and confirm you can still log in. If you locked yourself out, your open session is your rescue line.

The most important settings

sudo nano /etc/ssh/sshd_config

Setting	Safe value	What it does
`Port 22`	e.g. `Port 2222`	Changes the port scanners expect
`PermitRootLogin no`	`no`	Blocks direct root login
`PasswordAuthentication no`	`no`	Disables password login (keys only)
`PubkeyAuthentication yes`	`yes`	Enables key-based login
`AllowUsers yeasin deploy`	your users	Only listed users may connect at all
`MaxAuthTries 3`	`3`	Limits login attempts per connection

Port 2222
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
AllowUsers yeasin
MaxAuthTries 3

Each of these lines removes one attack path:

PermitRootLogin no — attackers always try root first. Even with a good password, you do not want them hammering the most powerful account.
PasswordAuthentication no — once your keys work, this is the single biggest security upgrade. Nothing can be brute-forced if passwords are not accepted.
AllowUsers — even a valid password for an unused account (like guest) is now useless.

Note: On modern Ubuntu (22.04+), password authentication may be controlled by a drop-in file at /etc/ssh/sshd_config.d/*.conf, which overrides the main config. Check with grep -ri PasswordAuthentication /etc/ssh/ to make sure your change actually takes effect.

Changing the default port

Changing the port (e.g., Port 2222) is security through obscurity — it reduces automated bot noise dramatically, but a targeted attacker will scan all ports anyway. Treat it as noise reduction, not real security:

sudo ufw allow 2222/tcp

ssh -p 2222 yeasin@203.0.113.10

Order matters: open the firewall for the new port before restarting sshd, or you will lock yourself out.

Step 5: The Client-Side Config File

Tired of typing ssh -p 2222 yeasin@203.0.113.10? SSH has a built-in solution. Create ~/.ssh/config on your client:

nano ~/.ssh/config

Host myserver
    HostName 203.0.113.10
    User yeasin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Now connecting is simply:

ssh myserver

This also makes scp, rsync, and sftp use the same settings automatically. If you manage more than one server, this file will save you hours.

Step 6: Extra Hardening for Public Servers

If your server has a public IP, bots are already knocking on port 22 — check for yourself:

sudo journalctl -u ssh | grep -i failed | tail

You will likely see login attempts for root, admin, and test from IP addresses all over the world. Two more layers stop this completely.

1. Fail2ban — automatic attacker blocking

Fail2ban watches the logs and bans IPs after repeated failed attempts:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Status
|- Number of matches:  14
|- Currently banned:   2
`- Total banned:        9

On Debian and Ubuntu, fail2ban ships with a ready-made sshd jail; default is 5 failed attempts leading to a 10-minute ban. Adjust it in /etc/fail2ban/jail.local.

2. Firewall — allow only what you need

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw enable
sudo ufw status verbose

Warning: Before running ufw enable on a remote server, make sure your SSH port is allowed. Locking yourself out of a remote machine is a rite of passage — but not one you need to experience.

Common Mistakes and Troubleshooting

1. "Connection refused"
The server is reachable, but nothing is listening on that port. Check: is ssh running (sudo systemctl status ssh)? Is the firewall allowing the port? Are you connecting to the right port?

2. "Connection timed out"
Packets are not reaching the server. Check the IP address, cloud provider security groups (AWS/GCP/DigitalOcean firewalls are separate from ufw), and any network firewall in between.

3. Key login silently falls back to password
Usually permissions. On the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

And check the logs — they tell you exactly why a login failed:

sudo journalctl -u ssh -n 20

4. Locked yourself out after changing the port
This is why you never close the working session during changes. If it does happen: on a VPS, use the provider's web console to fix sshd_config; on a local machine, plug in a keyboard and monitor.

5. "Too many authentication failures"
Your client may be offering many keys. Fix it in ~/.ssh/config with IdentitiesOnly yes on that host, so only the right key is offered.

Summary

SSH is the encrypted standard for remote administration — everything you type and transfer is protected end to end.
Install the server with openssh-server, and immediately allow it through ufw.
Replace password login with ed25519 key pairs as soon as possible — it is both more secure and more convenient.
Harden the server in /etc/ssh/sshd_config: PermitRootLogin no, PasswordAuthentication no, and AllowUsers for your accounts.
Always test with sshd -t and keep your current session open while applying changes.
Use ~/.ssh/config on the client to turn long commands into ssh myserver.
Add fail2ban on public servers; bots are already trying your door.

Remote access is the gateway skill: once SSH feels natural, managing servers, deploying applications, and automating infrastructure all start from that same ssh command.

Linux File System Structure and Navigation

Yeasin's — Sun, 11 Oct 2026 17:55:00 +0000

Every Linux journey starts at the same place: the root directory, written as a single forward slash (/). Unlike Windows, which scatters files across multiple drives like C:\ and D:\, Linux organizes everything into one unified tree. Your USB drive, your configuration files, your terminal, even your running processes — they all live somewhere inside that one tree.

Understanding this structure is not optional knowledge. When an application fails to start, when a disk fills up, or when a security audit asks "who owns this file," the answer is almost always found by navigating the file system confidently. In this article, we'll walk through the Linux directory hierarchy from the top down, then master the commands that let you move through it efficiently.

The Filesystem Hierarchy Standard (FHS)

Linux distributions follow a shared layout called the Filesystem Hierarchy Standard (FHS), maintained by the Linux Foundation. The FHS defines what each major directory should contain, which means a script you write on Debian will very likely work the same way on Ubuntu, Fedora, or Arch — because /etc means the same thing everywhere.

Note: The FHS describes conventions, not strict laws. Some distributions and tools make small deviations, but the core layout described below is consistent across virtually all modern Linux systems.

The Root Directory (`/`) and Its Key Subdirectories

The top of the entire file system is / (pronounced "root"). Everything else sits underneath it. Let's look at the directories you'll interact with most often.

Directory	Purpose
`/home`	Personal user directories (e.g., `/home/yeasin`)
`/root`	Home directory of the root (administrator) user
`/etc`	System-wide configuration files
`/var`	Variable data: logs, caches, spool files, databases
`/usr`	User programs, libraries, documentation
`/tmp`	Temporary files, usually cleared on reboot
`/dev`	Device files representing hardware
`/proc`	Virtual filesystem exposing kernel and process info
`/boot`	Kernel and boot loader files
`/opt`	Optional/third-party software
`/mnt`	Temporary mount point for manually mounted filesystems
`/media`	Auto-mounted removable media (USB drives, DVDs)
`/bin`, `/sbin`	Essential user and administrator binaries
`/lib`	Shared libraries and kernel modules
`/srv`	Data served by the system (e.g., web or FTP content)
`/run`	Runtime data since boot (process IDs, sockets)

`/home` — Your Personal Space

Each regular user gets a directory here:

ls /home
# output:
# yeasin

Your documents, downloads, and personal configuration files (the "dotfiles" like ~/.bashrc) all live under /home/yourusername. This is the only directory where a normal user should freely create and delete files.

`/etc` — The Control Room

/etc holds plain-text configuration files for the entire system. This is where you'll go to change hostname settings, configure SSH, or edit system-wide shell behavior:

ls /etc | head
# output (partial):
# hostname
# hosts
# fstab
# ssh
# passwd

Warning: Editing files in /etc affects the whole system. A typo in a file like /etc/fstab can prevent your system from booting. Always back up a config file before modifying it:
sudo cp /etc/fstab /etc/fstab.bak

`/var` — Data That Changes

The name stands for "variable" — data that grows and changes while the system runs. The most important subdirectory for daily administration is /var/log, where the system writes its logs:

ls /var/log
# output (partial):
# auth.log
# syslog
# dmesg

When something breaks, /var/log is usually the first place to investigate.

`/tmp` — Use It, Don't Trust It

/tmp is world-writable and intended for short-lived files. On most modern distributions (including Debian and Ubuntu using systemd), its contents are cleared on every reboot. Never store anything there that you want to keep.

`/proc` and `/dev` — Files That Aren't Files

This is where Linux gets interesting. /proc is a virtual filesystem — it doesn't exist on disk. The kernel generates its contents in memory to expose live system information as if it were files:

cat /proc/cpuinfo        # live CPU information
cat /proc/meminfo        # live memory usage
ls /proc/self            # info about the currently running shell process

Similarly, /dev contains device files. Your terminal, your disks, and /dev/null (the famous "black hole" that discards anything written to it) all appear here as files. This "everything is a file" design is one of Linux's most powerful ideas.

`/usr` and the Merged `/bin`, `/sbin`, `/lib`

Historically, /bin held essential command binaries and /usr/bin held less critical programs. Modern Debian (since Debian 11 "Bullseye") and Ubuntu (since 19.04) implement usrmerge: /bin, /sbin, and /lib are now symlinks pointing into /usr:

ls -l /bin
# output:
# lrwxrwxrwx 1 root root 7 ... /bin -> usr/bin

You can still type /bin/bash and it works — but on modern systems, the real files live under /usr/bin.

Absolute vs. Relative Paths

A path describes a file or directory's location in the tree. There are two kinds:

Absolute path — starts from /. It works from anywhere:

cd /var/log

Relative path — starts from your current location. It only works relative to where you are:

cd log        # only works if you're already inside /var

Two special notations power relative paths:

Symbol	Meaning
`.`	The current directory
`..`	The parent directory (one level up)
`~`	Your home directory (shortcut)
`-`	The previous directory you were in (with `cd`)

So if you are in /var/log, then .. means /var, and ../spool means /var/spool.

Navigation Commands You'll Use Every Day

`pwd` — Where Am I?

pwd (print working directory) shows your absolute current location:

pwd
# output:
# /var/log

The prompt often shows your location, but pwd is the definitive answer. Use it whenever you're disoriented.

`cd` — Change Directory

The workhorse of navigation:

cd /etc              # go to /etc (absolute)
cd ssh               # go to ./ssh (relative)
cd ..                # go up one level
cd                   # go to your home directory
cd ~                 # same as above
cd -                 # go back to the previous directory
cd /home/yeasin/Documents   # jump anywhere with an absolute path

A useful habit: after cd -, bash prints the directory you switched to, which is handy for bouncing between two distant locations:

cd /var/log
cd /etc
cd -
# output:
# /var/log

`ls` — Look Around

ls lists directory contents. Its most useful flags:

ls                  # basic listing
ls -l               # long format: permissions, owner, size, date
ls -a               # include hidden files (starting with .)
ls -la              # both combined
ls -lh              # long format with human-readable sizes (K, M, G)
ls -R               # recursive listing of subdirectories
ls -ld /var         # details of the directory itself, not its contents
ls -lt              # sort by modification time, newest first

Example output:

ls -lh /etc/hostname
# output:
# -rw-r--r-- 1 root root 8 Oct 12 09:41 /etc/hostname

Tip: Files whose names begin with a dot (like .bashrc) are hidden from normal ls output. Use ls -a to see them. Most of your shell's personal configuration lives in these files.

`tree` — See the Structure at a Glance

tree displays directories as an indented hierarchy — excellent for exploring unfamiliar territory:

tree -L 2 /etc/ssh
# output:
# /etc/ssh
# ├── moduli
# ├── ssh_config
# ├── sshd_config
# └── ssh_host_rsa_key

On Debian/Ubuntu, install it first:

sudo apt install tree

The -L flag limits the depth, which keeps output readable on large directories.

Practical Workflow: Exploring an Unfamiliar System

Here's a realistic scenario: you've just logged into a new server and need to get oriented.

Step 1 — Confirm where you are and who you are:

pwd
whoami

Step 2 — Check the top-level layout and disk usage:

ls /
df -h

Step 3 — Investigate the logs to see the system's recent activity:

cd /var/log
ls -lt | head

Step 4 — Check what services are configured:

ls /etc/ssh
cat /etc/hostname

Within a minute, you know the OS layout, available disk space, recent log activity, and configured services — all through navigation alone.

Common Mistakes and Troubleshooting

Mistake 1: Confusing /root with /

/ is the root of the entire file system. /root is the home directory of the administrator user. They look similar but are completely different places.

Mistake 2: Spaces in paths

cd /home/yeasin/My Documents
# bash: cd: too many arguments

The shell splits arguments at spaces. Quote the path instead:

cd "/home/yeasin/My Documents"

Mistake 3: Assuming . is always safe in scripts

A relative path like ./script.sh depends on the current directory. In scripts, prefer absolute paths for anything critical.

Mistake 4: Forgetting that cd requires execute permission on the target

To cd into a directory, you need execute (x) permission on it — not read. If you get Permission denied while navigating, check permissions with ls -ld /path/to/dir.

Mistake 5: Editing files in /etc without a backup

Covered above, but worth repeating: this is the single most common way beginners break a working system.

Summary and Key Takeaways

Linux uses one unified tree rooted at /, standardized by the FHS — no drive letters.
Learn the core directories: /etc for config, /var/log for logs, /home for users, /proc for live kernel data.
Absolute paths start with /; relative paths depend on your current location. .., ~, and - are your shortcuts.
Master pwd, cd, ls, and tree — these four commands cover 95% of daily navigation.
Modern Debian and Ubuntu merge /bin, /sbin, and /lib into /usr; the old paths still work as symlinks.
Before editing anything in /etc, make a backup copy.

The file system hierarchy rewards curiosity. The next time you're unsure what something does, cd into it, ls it, and cat the files. On Linux, the system rarely hides from you — you just need to know where to walk.

What directory confused you the most when you started with Linux? Share it in the comments — it's probably someone else's question too.

Managing Users and Groups in Linux: A Beginner-Friendly Guide

Yeasin's — Sat, 10 Oct 2026 01:57:40 +0000

Linux is a multi-user system. That means many people (and many programs) can use the same computer at the same time — but each one gets its own separate identity and its own limits.

Every person who logs in, and every service that runs in the background, has its own user account. This is how Linux decides:

Which files you can open
Which programs you can run
Who is allowed to use sudo
Which service can touch which files

If you want to manage a Linux server — or even just understand your own system better — users and groups are the first thing you need to learn.

In this guide, we will go step by step: what users and groups are, where Linux stores this information, and how to create, change, and delete them safely.

What Is a User in Linux?

When you create a user, Linux gives that user two important numbers:

UID (User ID) — a unique number for the user
GID (Group ID) — a unique number for the user's main group

Your username is just a friendly label. Deep inside, Linux only cares about the numbers.

For example, when the system checks if you can open a file, it looks at your UID — not your name.

Linux has three main types of users:

Type	UID	Example
Root user	0	`root` — the superuser, can do anything
System users	1–999	`www-data`, `mysql`, `sshd` — used by services
Normal users	1000+	`yeasin`, `rahim` — real humans

Note: On Debian and Ubuntu, the first normal user you create during installation gets UID 1000.

What Is a Group?

A group is a collection of users. It makes sharing easy.

Example: you have a folder that only the "developers" team should edit. Instead of giving permission to each person one by one, you put them all in one group and give permission to that group.

Every user has:

One primary group — usually a group with the same name as the user. New files you create belong to this group.
Zero or more secondary groups — extra groups you join, like sudo or docker.

Where Linux Stores User Information

All user and group information lives in simple text files inside the /etc directory:

File	What it contains
`/etc/passwd`	All users: name, UID, home folder, shell
`/etc/shadow`	Encrypted passwords (only root can read it)
`/etc/group`	All groups and their members

Let's look at one line from /etc/passwd:

cat /etc/passwd

yeasin\:x:1000:1000\:MD Yeasin Ali:/home/yeasin:/bin/bash

Each part has a meaning, separated by :

yeasin — username
x — password is stored in /etc/shadow
1000 — UID
1000 — GID of the primary group
MD Yeasin Ali — full name / comment
/home/yeasin — home directory
/bin/bash — the shell used at login

Warning: Never edit these files by hand with a normal editor. One small mistake can lock you out of your whole system. Always use the commands shown below.

Creating a New User

Debian and Ubuntu have two commands for this, and mixing them up is very common.

Option 1: `adduser` — the easy way (recommended for beginners)

sudo adduser rahim

The command will ask you a few questions:

Adding user 'rahim' ...
Adding new group 'rahim' (1001) ...
Creating home directory '/home/rahim' ...
Copying files from '/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for rahim
Enter the new value, or press ENTER for the default
  Full Name []: Rahim Uddin

That's it. adduser does everything for you:

Creates the user
Creates a private group with the same name
Creates the home directory
Copies default files from /etc/skel (like .bashrc)
Sets the password

Tip: /etc/skel is the "skeleton" folder. Anything you put there is automatically copied into every new user's home directory. Great for default configs.

Option 2: `useradd` — the manual way

useradd is the basic, low-level command. By default it does very little — no home directory, no password. You have to ask for everything yourself:

sudo useradd -m -s /bin/bash -c "Rahim Uddin" rahim
sudo passwd rahim

Flag	Meaning
`-m`	Create the home directory
`-s`	Set the login shell
`-c`	Add a full name / comment
`-u`	Use a specific UID
`-e`	Set an expiry date for the account

Note: On Debian and Ubuntu, adduser is friendly and interactive. On other distros (like Fedora), adduser behaves like useradd. So it's good to know both commands.

Creating a user for a service (not a human)

When you deploy your own app, never run it as root. Create a special system user for it:

sudo adduser --system --group --no-create-home --shell /usr/sbin/nologin myapp

Now your app can run as myapp, with the minimum possible permissions. If an attacker ever compromises the app, they only get the myapp account — not root.

Changing an Existing User

Use usermod to change a user's settings:

# Add user to a group (secondary group)
sudo usermod -aG docker rahim

# Change the username
sudo usermod -l newname oldname

# Change the home directory and move the files
sudo usermod -d /home/newname -m newname

# Lock the account (user cannot log in)
sudo usermod -L rahim

# Unlock the account
sudo usermod -U rahim

Warning: With -G, always include -a (append). sudo usermod -G docker rahim without -a removes rahim from all his other groups — including sudo. That can lock you out of admin access on your own machine. Write it as -aG, always.

Deleting a User

# Delete the user, keep the home directory
sudo userdel rahim

# Delete the user AND the home directory
sudo userdel -r rahim

Before deleting, it's smart to check what files the user still owns:

sudo find / -user rahim 2>/dev/null

If you delete a user but keep their files, those files will show a number instead of a name:

-rw-r--r-- 1 1001 1001 1024 Oct 10 12:00 notes.txt

That 1001 is the old UID. If a new user gets UID 1001 later, they suddenly own those files. So either delete the files or give them to someone else first.

Managing Groups

Create a group

sudo groupadd developers

Delete a group

sudo groupdel developers

Add a user to a group

sudo usermod -aG developers rahim

Or with gpasswd:

sudo gpasswd -a rahim developers

Remove a user from a group

sudo gpasswd -d rahim developers

Check which groups a user belongs to

groups rahim

Or get full details:

id rahim

uid=1002(rahim) gid=1002(rahim) groups=1002(rahim),27(sudo),1001(developers)

Important: Group changes apply on the next login. If you just added yourself to a group in your current session, log out and log back in for it to take effect.

The `sudo` group is special

On Debian and Ubuntu, anyone in the sudo group can use sudo. That's the whole mechanism. Want to make someone an admin? Just:

sudo usermod -aG sudo rahim

Real-World Example: A Shared Project Folder

Let's put it all together with a common real situation.

Your team has a folder, and three people need to edit the same files. Here's how to set it up cleanly.

Step 1 — Create a shared group:

sudo groupadd webteam

Step 2 — Add the users to the group:

sudo usermod -aG webteam yeasin
sudo usermod -aG webteam rahim
sudo usermod -aG webteam karim

Step 3 — Create the folder and give it to the group:

sudo mkdir -p /srv/webproject
sudo chown -R \:webteam /srv/webproject
sudo chmod -R 2775 /srv/webproject

What does 2775 mean?

2775 = special bit 2 + normal permissions 775
The 2 is the setgid bit. It makes every new file inside this folder automatically belong to webteam, no matter who creates it.
775 means: owner can do everything, group members can do everything, others can only read and open the folder.

Step 4 — Verify:

ls -ld /srv/webproject

drwxrwsr-x 2 root webteam 4096 Oct 10 12:00 /srv/webproject

Now when rahim creates a file, karim can edit it too — automatically. No manual permission fixing needed.

Common Mistakes and Fixes

1. Using usermod -G without -a

This removes the user from all their other groups. Fix it by adding them back:

sudo usermod -aG sudo rahim

2. Editing /etc/passwd by hand

One typo and you may not be able to log in anymore. If you must edit it, use the safe tools:

sudo vipw

vipw checks the file for mistakes before saving.

3. "I'm in the group, but I still get permission denied"

Group changes need a new login. Log out and back in — or use this for a quick fix:

newgrp docker

4. A deleted user's files show numbers instead of names

The UID no longer matches any user. Delete those files, or give them a new owner:

sudo chown -R yeasin\:yeasin /var/oldstuff

5. Checking why a user cannot log in

getent passwd rahim     # is the shell set to nologin?
sudo passwd -S rahim    # is the account locked?
sudo chage -l rahim     # any expiry date?

Summary

Here are the key points from this guide:

Linux identifies every user by a UID, and permissions are always checked against numbers, not names.
User data lives in /etc/passwd, /etc/shadow, and /etc/group — never edit them by hand.
Use adduser for easy, interactive user creation on Debian/Ubuntu.
Use usermod -aG to add users to groups — never forget the -a.
The sudo group is what gives someone admin power.
Create a separate system user for every service you deploy.
Use the setgid bit (2775) on shared folders so group permissions flow automatically to new files.

Once you understand users and groups, everything else in Linux security starts to make sense — because almost every permission question comes down to one simple thing: who is asking, and are they allowed?

Linux File Permissions: Understanding chmod and chown

Yeasin's — Thu, 08 Oct 2026 12:33:52 +0000

If you have ever seen the error "Permission denied" on a Linux system, you have already met file permissions. Every file and directory on a Linux system has an owner, a group, and a set of permissions that decide exactly who can read, write, or execute it.

Understanding chmod and chown is one of the most practical skills for any Linux user, developer, or system administrator. In this article, we will break it down step by step.

How Linux Views File Permissions

Run this command on any file:

ls -l file.txt

You will see something like this:

-rw-r--r-- 1 deploy deploy 2048 Oct  8 10:24 file.txt

The first part (-rw-r--r--) is the permission string. Let's decode it:

Position	Meaning
1st character	File type (`-` = file, `d` = directory, `l` = symlink)
Characters 2–4	Permissions for the owner (`rw-`)
Characters 5–7	Permissions for the group (`r--`)
Characters 8–10	Permissions for others (`r--`)

Each permission has a meaning:

r (read) — view the file contents (or list a directory)
w (write) — modify the file (or create/delete files inside a directory)
x (execute) — run the file as a program (or enter a directory)

Note: For directories, x means "can enter". Without it, you cannot cd into the directory, even if you can read it.

chown: Changing Ownership

The chown command changes who owns a file.

Basic syntax:

chown owner\:group file

Practical examples:

# Change the owner to "deploy"
sudo chown deploy file.txt

# Change both owner and group
sudo chown deploy\:deploy file.txt

# Recursively change ownership of a whole directory
sudo chown -R deploy\:deploy /var/www/app

Warning: chown usually requires sudo. Be careful with -R — it changes everything inside the directory, including files you may not expect. A wrong recursive chown on a system directory can break your system.

chmod: Changing Permissions

While chown decides who, chmod decides what they can do.

There are two ways to use chmod:

1. Symbolic Mode (letters)

chmod u+x script.sh

u = owner (user), g = group, o = others, a = all
+ adds a permission, - removes it, = sets it exactly

Examples:

chmod u+x script.sh       # Owner can execute
chmod g-w file.txt        # Remove write from group
chmod a=r file.txt        # Everyone can only read
chmod u=rwx,g=rx,o= file.txt  # Full control for owner, read+execute for group, nothing for others

2. Numeric (Octal) Mode

Each permission has a value:

r = 4
w = 2
x = 1

You add them up for each category (owner, group, others):

Number	Permission
7	rwx (4+2+1)
6	rw- (4+2)
5	r-x (4+1)
4	r--
0	---

So:

chmod 755 script.sh

means:

Owner: 7 → read, write, execute
Group: 5 → read, execute
Others: 5 → read, execute

Common real-world values:

chmod 644 file.txt      # Normal file: owner reads/writes, everyone else reads
chmod 755 script.sh     # Executable script or open directory
chmod 600 ~/.ssh/id_ed25519   # Private SSH key: only owner can read/write
chmod 700 ~/.ssh        # SSH directory: only owner has full access

Tip: The 600 permission on SSH private keys is not optional. ssh will refuse to use a private key that others can read.

A Real-World Scenario

Imagine you deploy a web app on an Ubuntu server:

sudo chown -R www-data\:www-data /var/www/app
sudo chmod -R 755 /var/www/app

www-data is the user the web server runs as on Debian/Ubuntu.
755 lets the web server read and use the files, while other users can read but not modify them.
Secrets like .env should be locked down further:

sudo chmod 640 /var/www/app/.env

This is the everyday reality of permissions: give the minimum access needed, and nothing more.

Common Mistakes and Troubleshooting

chmod 777 as a "fix" — It makes the file writable by everyone. It often "works", but it is a security hole. Almost always, the correct answer is proper ownership, not 777.
Forgetting -R on directories — chmod 644 mydir changes the directory itself, not its contents.
Removing x from a directory — You lose the ability to enter it, even as the owner.
Ownership vs permission confusion — If you own a file, you can change its permissions even without write access to the file itself.

Quick diagnostic habit:

ls -l file.txt        # Who owns it? What are the permissions?
id                    # What groups am I in?
namei -l /var/www/app/index.html   # Check permissions on every level of the path

The namei -l trick is underrated — "Permission denied" can come from any parent directory in the path, not just the file itself.

Summary

Every file has an owner, a group, and others, each with r, w, and x permissions.
chown changes who owns a file; chmod changes what they can do.
Symbolic mode (u+x) is readable; numeric mode (755) is compact and fast.
Follow the principle of least privilege: give the minimum permission required.
Avoid chmod 777. Diagnose with ls -l, id, and namei -l instead.

Once this clicks, "Permission denied" stops being a mystery and becomes a simple question: who owns this file, and what are they allowed to do?

Linux Server User Management: A Complete Practical Guide

Yeasin's — Wed, 07 Oct 2026 13:18:35 +0000

Introduction

Every Linux server, whether it hosts a small personal project or a large-scale production application, depends on one fundamental administrative task: user management. Properly managed users and groups are the first line of defense for your server's security, and they form the foundation of a well-organized, maintainable system.

When I first started working with Linux servers, user management seemed like a simple topic — just create a user, set a password, and move on. In practice, it is much more than that. Understanding how users, groups, permissions, and privileges work together is essential for anyone who administers a server, whether you are a DevOps engineer, a backend developer deploying your first application, or a student building a home lab.

In this article, I will walk you through everything you need to know about user management on a Linux server: creating and deleting users, managing groups, assigning sudo privileges, securing SSH access, and following industry best practices.

Why User Management Matters

Before diving into commands, it is important to understand why this topic deserves your attention:

Security: Each user account is a potential entry point. Unused accounts, weak passwords, and excessive privileges are among the most common ways servers get compromised.
Accountability: When every action can be traced back to a specific user, auditing and troubleshooting become far easier.
Least privilege: Users should only have the access they actually need — no more, no less.
Collaboration: Groups allow teams to share files and resources safely without exposing them to everyone else.

Understanding Users in Linux

In Linux, every user is identified by two values:

Username: The human-readable name used to log in (for example, yeasin).
UID (User ID): The numeric identifier the system actually uses internally. Regular users typically start at 1000, while system accounts use lower values.

User information is stored in a few key files:

File	Purpose
`/etc/passwd`	Stores usernames, UIDs, home directories, and default shells
`/etc/shadow`	Stores encrypted passwords and password aging policies
`/etc/group`	Stores group names, GIDs, and group memberships
`/etc/sudoers`	Defines which users or groups may run commands with `sudo`

You should never edit these files directly with a text editor. Instead, use the dedicated commands covered below, which handle locking and validation for you.

Creating Users

1. Adding a New User

The standard command to create a user is useradd, but on most modern distributions, adduser is a friendlier, interactive alternative.

sudo adduser yeasin

This command automatically:

Creates the user,
Assigns a UID,
Creates a home directory at /home/yeasin,
Copies default configuration files into the home directory,
Prompts you to set a password and optional details.

If your distribution only ships the low-level useradd command, create a user with a home directory and Bash shell like this:

sudo useradd -m -s /bin/bash yeasin
sudo passwd yeasin

Here, the -m flag creates the home directory, and -s sets the default shell.

2. Verifying the User

Confirm that the user was created correctly:

id yeasin

Example output:

uid=1001(yeasin) gid=1001(yeasin) groups=1001(yeasin)

Managing Passwords and Account Policies

A strong password policy is a core part of server security. Set or change a user's password with:

sudo passwd yeasin

You can also enforce password aging so that passwords expire periodically:

sudo chage -M 90 yeasin

This forces the user to change their password every 90 days. To review a user's password policy:

sudo chage -l yeasin

For production servers, consider requiring strong passwords using PAM (Pluggable Authentication Modules) configuration, and always prefer key-based authentication over passwords for remote access.

Working with Groups

Groups make permission management dramatically simpler. Instead of assigning permissions to users one by one, you assign them to a group once.

1. Creating a Group

sudo groupadd developers

2. Adding a User to a Group

sudo usermod -aG developers yeasin

The -aG flags are critical: -a appends the user to the group without removing them from other groups, and -G specifies the group. If you omit -a, the user will be removed from all their other secondary groups — a common and painful mistake.

Verify group membership after the user logs in again:

groups yeasin

3. Deleting a Group

sudo groupdel developers

Granting Sudo Privileges

Sometimes a user needs administrative rights. There are two recommended ways to grant them.

1. Using the Sudo Group

On Ubuntu and Debian, members of the sudo group automatically receive administrative privileges:

sudo usermod -aG sudo yeasin

On CentOS, RHEL, and Fedora, the equivalent group is called wheel:

sudo usermod -aG wheel yeasin

2. Using a Custom Sudoers File

For fine-grained control, create a dedicated sudoers file for the user:

sudo visudo -f /etc/sudoers.d/yeasin

Add this line to allow full access:

yeasin ALL=(ALL:ALL) ALL

Always use visudo when editing sudo configuration. It validates the syntax before saving, which prevents you from accidentally locking yourself out of administrative access.

Locking, Unlocking, and Deleting Users

1. Locking an Account

When someone leaves a team, disable their account immediately:

sudo usermod -L yeasin

Unlock it later if needed:

sudo usermod -U yeasin

2. Deleting a User

To remove a user along with their home directory and mail spool:

sudo userdel -r yeasin

Double-check the username before running this command, because deletion is permanent.

Securing SSH Access

User management on a server goes hand in hand with SSH security. A few essential practices:

1. Use Key-Based Authentication

Generate a key pair on your local machine:

ssh-keygen -t ed25519

Copy the public key to the server:

ssh-copy-id yeasin@your-server-ip

2. Disable Root Login and Password Authentication

Edit the SSH daemon configuration at /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no

Then restart the SSH service:

sudo systemctl restart sshd

3. Restrict Which Users Can Log In

Allow only specific users to connect over SSH:

AllowUsers yeasin deploy

Keep an SSH session open while testing configuration changes, so you never lock yourself out of your own server.

Best Practices Checklist

To summarize the habits of a well-managed server:

Create a separate user for every person and every service; never share accounts.
Disable root login over SSH and use sudo for administrative tasks instead.
Prefer key-based authentication over password authentication.
Apply the principle of least privilege: grant only the access a user actually needs.
Regularly audit accounts with last, lastlog, and /var/log/auth.log.
Lock or delete accounts as soon as they are no longer needed.
Enforce password aging policies with chage where key-based login is not possible.

Conclusion

User management may appear to be a basic administrative chore, but it is genuinely one of the most important pillars of Linux server security. A server with carefully controlled users, groups, and privileges is dramatically harder to compromise, far easier to audit, and much simpler to maintain over time.

The commands in this guide are the same ones used daily by professional system administrators. Practice them on a virtual machine or a cloud instance, break things safely, and rebuild your understanding from the ground up. The more comfortable you become with user management, the more confident you will feel running production servers.

If you found this guide helpful, consider saving it for reference and sharing it with others who are learning Linux administration.

Thank you for reading.

DEV Community: Yeasin's

File and Directory Management in Linux

The Linux Directory Structure: Start Here

Absolute vs relative paths

Navigating: pwd, ls, and cd

Where am I? — pwd

What's here? — ls

Moving around — cd

Creating Files and Directories

Touch — create an empty file

mkdir — create directories

Creating files with content

Copying and Moving

cp — copy

mv — move and rename

Deleting: rm, rmdir, and Staying Safe

rm — delete files

rmdir — the cautious alternative

Safer deletion patterns

Viewing Files

Finding Files: find and locate

find — powerful, real-time search

locate — fast, database-based

Wildcards: The Pattern Language of the Shell

A Practical Workflow: Organizing a Messy Folder

Common Mistakes and Troubleshooting

Summary

SSH and Remote Access Configuration in Linux

What Is SSH and Why Does It Matter?

How SSH Works: The Basic Flow

Step 1: Installing the SSH Server

Step 2: Connecting for the First Time

Step 3: Key-Based Authentication (Do This First)

Generate a key pair

Copy the public key to the server

Step 4: Understanding and Configuring sshd

The most important settings

Changing the default port

Step 5: The Client-Side Config File

Step 6: Extra Hardening for Public Servers

1. Fail2ban — automatic attacker blocking

2. Firewall — allow only what you need

Common Mistakes and Troubleshooting

Summary

Linux File System Structure and Navigation

The Filesystem Hierarchy Standard (FHS)

The Root Directory (/) and Its Key Subdirectories

/home — Your Personal Space

/etc — The Control Room

/var — Data That Changes

/tmp — Use It, Don't Trust It

/proc and /dev — Files That Aren't Files

/usr and the Merged /bin, /sbin, /lib

Absolute vs. Relative Paths

Navigation Commands You'll Use Every Day

pwd — Where Am I?

cd — Change Directory

ls — Look Around

tree — See the Structure at a Glance

Practical Workflow: Exploring an Unfamiliar System

Common Mistakes and Troubleshooting

Summary and Key Takeaways

Managing Users and Groups in Linux: A Beginner-Friendly Guide

What Is a User in Linux?

What Is a Group?

Where Linux Stores User Information

Creating a New User

Option 1: adduser — the easy way (recommended for beginners)

Option 2: useradd — the manual way

Creating a user for a service (not a human)

Changing an Existing User

Deleting a User

Managing Groups

Create a group

Delete a group

Add a user to a group

Remove a user from a group

Check which groups a user belongs to

The sudo group is special

Real-World Example: A Shared Project Folder

Where am I? — `pwd`

What's here? — `ls`

Moving around — `cd`

The Root Directory (`/`) and Its Key Subdirectories

`/home` — Your Personal Space

`/etc` — The Control Room

`/var` — Data That Changes

`/tmp` — Use It, Don't Trust It

`/proc` and `/dev` — Files That Aren't Files

`/usr` and the Merged `/bin`, `/sbin`, `/lib`

`pwd` — Where Am I?

`cd` — Change Directory

`ls` — Look Around

`tree` — See the Structure at a Glance

Option 1: `adduser` — the easy way (recommended for beginners)

Option 2: `useradd` — the manual way

The `sudo` group is special