Know What You Protect on Your Raspberry Pi

Before disabling a service or changing SSH, write down what the Pi does, who can reach it and how you would recover access. A useful security checklist connects each change to a concrete risk; it is not a list of settings to switch off.

Outcome: a short protection and recovery worksheet for your own Pi. You need a working Raspberry Pi OS or Ubuntu installation and basic terminal access. The commands below inspect the host; they do not change its configuration.

Start with a familiar example

Consider a Pi that records camera images and serves them over your home network. Its assets include the recordings, the login credentials and the availability of the recorder. A visitor on your Wi-Fi, an Internet user and a program running on the Pi have different access paths.

“Protect my Pi” is too broad to verify. “Only my household account may read recordings, and I can restore yesterday's images” gives you two outcomes to check. For a disposable OLED demo, the valuable item might instead be the source code and the ability to rebuild it.

1. Identify the host and account

Run on the Pi host, not just inside a container:

cat /etc/os-release
uname -r
id
findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS /

Record the distribution/release, running kernel, current user/groups and root filesystem. Keep device identifiers and network information private when sharing reports. A familiar desktop appearance is not sufficient evidence of which OS or kernel package you have.

id lists memberships, not every permission the account can obtain. An account allowed to use sudo or control a privileged management socket can have substantially more power than an ordinary file owner.

2. List the data and services that matter

Write down these four categories without copying passwords into the worksheet:

• Data: project files, recordings, databases, configurations and backups.
• Credentials: SSH private keys, API tokens, application passwords and recovery keys. Record their storage location and custodian, not the secret value.
• Availability: the services that must keep working, such as DNS, storage or a sensor recorder.
• Access paths: local console, SSH, remote desktop, VPN, public website and people allowed to use them.

An inventory of running services can help, but a process name is not a reason to stop it:

systemctl --no-pager --type=service --state=running
ss -lnt
ss -lnu

These commands show activity and listening sockets. They do not prove that a service is reachable from the Internet or that it is safe. Processes inside containers, port forwarding and VPN routes can require additional investigation; the network exposure lesson covers that next layer.

3. Name a threat and a boundary

For each important item, complete: “I want to prevent this actor from this action through this route.” For example:

• A household guest should not read camera recordings through a shared folder.
• A compromised web application should not read the account's SSH private key.
• A failed storage device should not destroy the only copy of a project.

The first two concern who may cross an access boundary. The third concerns recovery and availability; it needs a backup, not merely a stronger password. Encryption, permissions and backups solve different problems.

Also state what you trust. If you deliberately run an unreviewed script as root, changing one directory's mode is not a complete defense against that script. Start with least privilege: grant only the access needed for the task, and explain any exception.

4. Prepare recovery before restricting access

Before a change that could interrupt access, answer all of these:

1. Can you open a second session now, without closing the working one?
2. If networking fails, can you use a local console or another independent path?
3. Is the relevant configuration backed up privately, and can you identify the exact original settings?
4. Can the Pi be interrupted without breaking another essential service?
5. Can you explain how to reverse this specific change from the recovery path?

A VPN and SSH over the same failed network interface are not independent recovery routes. A backup stored only on the failing boot disk is not an independent copy. Do not proceed with an access restriction if the answers are unknown.

Your one-page worksheet

Store this privately. Fill in one proposed change first rather than redesigning the whole system:

Pi purpose / OS / responsible person:
Important data and where independent backups live:
Credential locations (no secret values):
Required services and acceptable downtime:
Who may reach each service, and from where:
One threat and the boundary it would cross:
Proposed change and why it addresses that threat:
Original setting / private backup location:
Independent recovery route:
Permitted action that must still work:
Disallowed action to check safely:
Exact reversal and the point at which to stop:

Check the result: can another administrator understand what must remain working and how to recover, without receiving your private keys? If not, refine the worksheet before applying a hardening recipe.

Common mistakes

“It is on my LAN, so everyone is trusted.” Consider guest devices, compromised machines and the applications you run, not just the router boundary.

“A command finished, so the change worked.” Verify both intended access and a harmless denied action. Never test by damaging real data or running an exploit.

“Undo means reset everything.” Broad resets can remove unrelated working settings. Record one change and its specific reversal.

Verification and next step

Read-only host/account/filesystem/service/socket inspection was checked on Pi 4B, Debian 13, kernel 6.18.50+rpt-rpi-v8 on 31 October 2026. This is not a penetration test or a security certification, and no host settings were changed.

Use Raspberry Pi's OS documentation and Ubuntu's security documentation as the starting points for platform-specific controls.

Checkpoint: why does a backup not replace permissions, and why does a second SSH window not guarantee recovery from a network failure?

Next: check packages, update deliberately and verify the running kernel. Return to Security for the full path.