LPIC-1 102: Security

Source status

Source status: LPI LPIC-1 overview verified July 3, 2026. Current version 5.0; exams 101-500 and 102-500.

This page paraphrases study areas into command practice. It does not copy official objective text wholesale and is not an exam dump.

Plain-English goal

Practice area: security review, SUID/SGID, password aging, limits, sudo, open ports, SSH, host security, and encryption basics. Exam/domain: 102-500.

read the situation

Command, output, and next step

Command anatomy

getent group sudo wheel admin 2>/dev/null; sudo -l 2>/dev/null || true

getent: the command family
flags: change output shape or scope
target: the file, service, user, mount, or host being inspected
output: evidence you must explain before changing state

Annotated output

Usage: command [OPTION]... TARGET
Try 'command --help' for common flags.
Try 'man command' for full reference.

What to notice

Usage: the command shape and expected target
--help: quick option reference
man: full local manual page when installed

Safe vs unsafe move

Common wrong move

Treating a practice command as a permission to make a broad production change.

Next safe command

command --help

Troubleshooting ladder

Name the symptom.
Inspect read-only state.
Find the owner, service, file, device, mount, or route.
Read the decisive output field.
Choose the next narrow command.
Avoid broad or destructive changes.
Make the smallest justified change if required.
Verify and record what changed.

How to get help

Know the commandUse command --help, then man command for the full reference.
Know the conceptUse apropos keyword or man -k keyword to discover command names.
Maybe a shell builtinUse type command, command -V command, then help command.
Service behaviorUse systemctl status service and journalctl -u service before restarting.
Package ownershipUse dpkg -S, rpm -qf, or the distro package tool for the installed file.

Study plan

Start with read-only exposure review: login shells, privileged groups, sudo grants, recent auth events, open listeners, and suspicious file modes.
Practice file security from path traversal to ACLs: owner, group, mode, SUID/SGID/sticky bits, loose private keys, and world-writable paths.
Review SSH client and server basics: keys, known hosts, host keys, authorized_keys modes, password auth, tunnels, and X11 forwarding risk.
Understand encryption practice at the command line: GnuPG encrypt/sign/verify/revoke concepts and safe handling of private material.

Command labs

Run these in a lab shell or disposable machine first. The point is to explain the output, not just memorize the command.

Review privileged access

getent group sudo wheel admin 2>/dev/null; sudo -l 2>/dev/null || true

Privileged groups and current sudo rights should be inspected before changes.

Annotated output

Usage: command [OPTION]... TARGET
Try 'command --help' for common flags.
Try 'man command' for full reference.

What to notice: Usage, --help, man.

Next safe command: command --help

Find risky file permissions

find /usr /bin /sbin -xdev -perm /6000 -type f -printf '%m %u:%g %p\n' 2>/dev/null | head -40

SUID/SGID files should be listed for review, not automatically changed.

Annotated output

root 524288000 2026-07-03 /var/log/journal/2f/system.journal
www-data 248512000 2026-07-02 /var/log/nginx/access.log
deploy 146800640 2026-07-01 /var/tmp/app-export.tar

What to notice: owner, bytes, date, path.

Next safe command: du -xhd1 /var | sort -h

Inspect SSH key permissions

namei -l ~/.ssh/authorized_keys 2>/dev/null; stat -c '%a %U:%G %n' ~/.ssh ~/.ssh/authorized_keys 2>/dev/null

SSH directory and authorized_keys modes should be tight enough for OpenSSH to accept them.

Annotated output

f: /srv/app/current/.env
drwxr-xr-x root root /
drwxr-xr-x root root srv
drwxr-x--- deploy www-data app
drwxr-x--- deploy www-data current
-rw------- deploy deploy .env

uid=33(www-data) gid=33(www-data) groups=33(www-data)

What to notice: each path segment, mode, owner/group, effective user.

Next safe command: systemctl show nginx -p User -p Group

command families

Commands to practice

find
stat
chmod
chown
getfacl
setfacl
sudo
su
passwd
chage
ulimit
ss
ssh
ssh-keygen
gpg
ufw
firewall-cmd
iptables

Related drills

Flashcards

Why audit SUID/SGID files instead of removing bits immediately?

Some are required for normal system behavior; changes need context and rollback.

Why do SSH key file modes matter?

OpenSSH can reject keys if directories or key files are too open.

What does sudo -l show?

The commands the current user may run through sudo, if permitted.

What is the difference between signing and encrypting with GnuPG?

Signing proves authorship/integrity; encryption hides content from anyone without the private key.

Quick quiz

Check the reasoning locally in your browser. Answers are not sent anywhere.

Which command safely reviews special permission bits?

A. find /usr -perm /6000 -type f -print B. chmod -R 777 /usr C. rm -rf / D. mkfs.ext4 /dev/sda

Show answer

Answer: find /usr -perm /6000 -type f -print

Why: find can list SUID/SGID files for review.

chmod -R 777 /usr: That changes access broadly before proving which path component or owner is wrong.
rm -rf /: That destroys or removes state before the evidence is understood.
mkfs.ext4 /dev/sda: That destroys or removes state before the evidence is understood.

Which check helps explain rejected SSH keys?

A. namei/stat on ~/.ssh and authorized_keys B. df -h only C. lpq D. locale

Show answer

Answer: namei/stat on ~/.ssh and authorized_keys

Why: Directory and file modes are common SSH auth blockers.

df -h only: That does not answer the question the output is asking you to prove first.
lpq: That does not answer the question the output is asking you to prove first.
locale: That does not answer the question the output is asking you to prove first.

What should happen before changing firewall or SSH settings remotely?

A. Confirm current access path and rollback B. Disable logs C. Delete keys D. Reboot blindly

Show answer

Answer: Confirm current access path and rollback

Why: Remote access changes can lock you out without a rollback path.

Disable logs: That does not answer the question the output is asking you to prove first.
Delete keys: That destroys or removes state before the evidence is understood.
Reboot blindly: That changes runtime state before reading the output that explains the failure.

visual practice

SSH trust sequence

Follow the two different trust checks SSH performs: host identity first, then user authentication.

Connect

The client opens a TCP connection to the SSH server.

ssh -vv user@host

Host key

The server proves its host identity. The client compares it with known_hosts.

ssh-keygen -F host

User key

The client offers a user key or other allowed authentication method.

ssh -v user@host 2>&1 | grep -i "Offering public key"

Authorization

The server checks authorized_keys, account state, permissions, and sshd policy.

namei -l ~/.ssh/authorized_keys

Session

Only after both trust checks pass does the shell or command session start.

whoami && id

Self-test before moving on

Can you inspect sudo exposure, login shells, and privileged groups without changing accounts? Can you identify risky file modes and explain which ones require careful review? Can you distinguish SSH key, host key, known_hosts, and authorized_keys responsibilities?

Source status

Plain-English goal

Command, output, and next step

What to notice

Common wrong move

Next safe command

Troubleshooting ladder

How to get help

Study plan

Command labs

Review privileged access

Find risky file permissions

Inspect SSH key permissions

Commands to practice

Related command pages

Related drills

Flashcards

Quick quiz

SSH trust sequence

Connect

Host key

User key

Authorization

Session

Self-test before moving on