Week 3 · Monday, September 14, 2026 · Room D-221

Same Pi, same drive, now updated, keyed and locked.

Your boot drive already carries a working system. Today you bring it up to date, teach it to recognise you by key instead of by password, close every network door except the ones you use, and demonstrate Assignment 1. These six pages are the whole path.

1 h theory 2 h lab Assignment 1 demo today (10 %)

What happens today

Theory · first hour

Who is allowed to do what

Users, passwords and why they are weak on a network. Key pairs: what stays secret, what travels. Ports and services: how a computer offers SSH or VNC to the network, and how a firewall decides who gets in.

Start with the key-pair idea →

Lab · two hours

Update, key, lock, demo

Boot the same drive as last week, run the apt update cycle, generate and install SSH keys (lab PC → Pi, and Pi → GitHub), enable UFW with SSH allowed, turn on VNC, then demonstrate Assignment 1 to the teacher.

Start with the update →

In the course outline

This is Week 3 of 420-302-VA. Assignment 1 (Git and GitHub, 10 %) is demonstrated in class today; work not demonstrated is marked late. This Friday, September 18, is the deadline to withdraw from a course without a transcript remark. Next week (Week 4, September 21) starts Python and GPIO on this same installation: bring the breadboard kit.

What is on the bench

Same station convention as last week: left set is the lab PC, right set is the Raspberry Pi. Check before wiring; the Week 2 wiring order still applies, power last.

My Raspberry Pi (4, 400 or 5) with the power supply rated for the model
The same labelled boot drive as Week 2 (microSD card or USB SSD): your hostname and account are on it
Pi screen, keyboard and mouse connected; screen on the Pi's HDMI input
Network: class Wi-Fi credentials or an Ethernet cable, as posted on the board
GitHub account details for both team members (Assignment 1 demo)
No breadboard needed today; it stays in the kit until Week 4

Why "secure configuration" before any IoT code

From Week 4 on, your Raspberry Pi is a network device that other machines talk to: the ESP32 publishes measurements to it, your browser reads dashboards from it, and you administer it over SSH. A device that accepts passwords from anywhere, runs outdated software and answers on every port is exactly how IoT systems get hijacked.

This is not hypothetical. In 2016 the Mirai botnet took over hundreds of thousands of IoT devices, cameras, routers, recorders, by doing nothing cleverer than trying a short list of factory passwords over the network, then used them to knock major websites offline. Every device it captured had exactly the weaknesses you remove today: a guessable password on an open port and software nobody updated. Weak default settings and missing updates still top OWASP's list of the most common IoT vulnerabilities. Today's four moves are the standard hardening baseline for any Linux server, scaled to a classroom:

Update: known security holes are fixed in newer packages. An unpatched system is an open one.
Keys instead of passwords: a key cannot be guessed, shoulder-surfed or reused from a leaked list.
Firewall: only the services you chose (SSH, VNC) are reachable. Everything else is refused before it reaches any program.
Deliberate remote access: VNC when you need a desktop, SSH for everything else, nothing you did not turn on.

Three ideas you will reuse for the rest of the course

The four stages are applications of three general security ideas. They come back in Week 9 (MQTT), Week 11 (the Flask web interface) and in the term project's "securely configured" criterion, so learn the names now:

Attack surface

Everything reachable from outside: open ports, running services, accounts that accept passwords. Smaller surface, fewer ways in. The firewall's default-deny and "no services you did not turn on" shrink yours to two doors.

Least privilege

Every actor gets the minimum access its job needs. Your account uses sudo only when required; a key installed on one machine opens only that machine; GitHub gets a public key, never a password. Week 9's MQTT users follow the same rule.

Defence in depth

Layers that each catch what the previous one misses: updated software, then a firewall, then key-based authentication, then your own habits. One layer failing (a leaked password) does not hand over the system.

These three terms are standard vocabulary in every security text; the exam and the project report may use them without re-explaining.

What you will be able to do by the end of the week

Run the full apt cycle (update, full-upgrade, autoremove), read what it tells you, and install or remove a package on purpose.
Explain what the private and public halves of an SSH key do, and where each one is allowed to live.
Log in to your Pi from the lab PC without typing a password, and push to GitHub from the Pi without typing one either.
Enable UFW with a default-deny policy that still lets SSH and VNC through, and read ufw status verbose.
Open your Pi's desktop from another computer with VNC, and say when SSH is the better tool.
Demonstrate Assignment 1: a shared repository with commits from every member and a Markdown README.

Words you will hear all day

Term	Plain meaning	Common mix-up to avoid
Package	A piece of software plus its metadata, installed by `apt` from Debian's repositories.	Not the same as a Python package installed with `pip`; that comes in Week 4.
Repository (apt)	A server full of packages that `apt update` reads the catalogue of.	Different thing from a Git repository, despite the shared name.
Key pair	Two matched files: a private key that never leaves the machine it was made on, and a public key you copy anywhere you want to log in.	Sharing the file ending in `.pub` is fine. Sharing the other one means making a new pair.
Service / daemon	A program that runs in the background and answers the network, like `sshd` for SSH.	A service listens even when no one is logged in; closing the terminal does not stop it.
Port	A numbered door on the network side of the OS. SSH answers on 22, VNC on 5900.	Software doors, not the physical USB or HDMI sockets.
Firewall	A filter that accepts or refuses connections per port, before any program sees them. Ours is UFW.	It filters the network. It does not scan files or stop you from breaking your own system locally.
Fingerprint	A short hash that identifies a key, safe to show and compare.	Showing a fingerprint is fine; it does not reveal the private key.

Where this fits in the course

Week 2 · Aug 31

Hardware, Imager, first boot, terminal

You built the platform: a booted, named, reachable Raspberry Pi and the commands to drive it.

Week 3 · Sep 14 · this hub

Secure configuration

The platform becomes trustworthy: patched, key-only where it matters, firewalled, remotely reachable on your terms. A1 demo.

Week 4 · Sep 21

Python environment and GPIO

First hardware control: a virtual environment, gpiozero, LEDs and buttons on the breadboard, over the SSH setup you build today.

Working at home

Everything today works on a home installation too (see Week 2, Working at home). Two differences: your home router usually blocks nothing on the local network, so UFW is your only door policy; and if you enable key-only login at home, keep a second way in (the desktop session, or a spare copy of the key) before you turn passwords off.