5 exercises on step-by-step technical guides — SSH key authentication and Python virtual environments. Read for sequence, prerequisites, conditions, and the all-important gotchas.
Reading step-by-step guides effectively
Prerequisites — what you need before Step 1; skipping these is the top cause of failure
Sequence gates — “Do NOT proceed until...” marks a condition that must be true first
Platform branches — match the command to your OS, not the first line you see
“Common gotcha” / WARNING — the trap others fall into; read these twice
Purpose of a precaution — ask “what bad outcome does this prevent?”
0 / 5 completed
1 / 5
Passage: SSH Key Setup — How-To Guide
Title: How to Set Up SSH Key Authentication for a Remote Server
Prerequisites: You need terminal access on your local machine and an existing way to
log in to the server (usually a password). This guide assumes OpenSSH, which ships with
macOS, Linux, and modern Windows.
Step 1 — Generate a key pair on your LOCAL machine (not the server):
ssh-keygen -t ed25519 -C "you@example.com"
Press Enter to accept the default location (~/.ssh/id_ed25519). You may set a
passphrase for extra security; if you do, you will be prompted for it when the key
is first used in a session.
Step 2 — Copy the PUBLIC key to the server:
ssh-copy-id user@your-server-ip
This appends your public key to ~/.ssh/authorized_keys on the server. You will be
asked for your password one last time.
Step 3 — Test the connection:
ssh user@your-server-ip
If everything worked, you log in without a password (or with only your key
passphrase). Do NOT proceed to Step 4 until this works.
Step 4 — (Optional but recommended) Disable password login on the server:
Edit /etc/ssh/sshd_config and set:
PasswordAuthentication no
Then restart SSH: sudo systemctl restart ssh
WARNING: If your key is not working and you disable password login, you will lock
yourself out. Always confirm Step 3 succeeds first. Keep a second terminal session
open while you test, so you are not relying on a single connection.
Common gotcha: If the server rejects your key, check that ~/.ssh on the server is
mode 700 and authorized_keys is mode 600. SSH silently refuses keys in
world-readable files as a security measure.
According to the guide, what must you confirm before disabling password login in Step 4?
Confirm Step 3 (key login) works first.
The guide is emphatic: "Do NOT proceed to Step 4 until this works" and again in the warning: "If your key is not working and you disable password login, you will lock yourself out. Always confirm Step 3 succeeds first."
Reading for sequence and conditions: How-to guides depend on order. Look for explicit gates: "Do NOT proceed until...", "only after...", "before you...". These mark a precondition that must be true before the next step is safe.
Why the distractors fail:
Option A — the passphrase is optional ("You may set a passphrase"), not a precondition for Step 4.
Option C confuses a tool used in Step 2 with a Step 4 requirement.
Option D reverses the goal — Step 4 sets password auth to no.
2 / 5
Passage: SSH Key Setup — How-To Guide
Title: How to Set Up SSH Key Authentication for a Remote Server
Prerequisites: You need terminal access on your local machine and an existing way to
log in to the server (usually a password). This guide assumes OpenSSH, which ships with
macOS, Linux, and modern Windows.
Step 1 — Generate a key pair on your LOCAL machine (not the server):
ssh-keygen -t ed25519 -C "you@example.com"
Press Enter to accept the default location (~/.ssh/id_ed25519). You may set a
passphrase for extra security; if you do, you will be prompted for it when the key
is first used in a session.
Step 2 — Copy the PUBLIC key to the server:
ssh-copy-id user@your-server-ip
This appends your public key to ~/.ssh/authorized_keys on the server. You will be
asked for your password one last time.
Step 3 — Test the connection:
ssh user@your-server-ip
If everything worked, you log in without a password (or with only your key
passphrase). Do NOT proceed to Step 4 until this works.
Step 4 — (Optional but recommended) Disable password login on the server:
Edit /etc/ssh/sshd_config and set:
PasswordAuthentication no
Then restart SSH: sudo systemctl restart ssh
WARNING: If your key is not working and you disable password login, you will lock
yourself out. Always confirm Step 3 succeeds first. Keep a second terminal session
open while you test, so you are not relying on a single connection.
Common gotcha: If the server rejects your key, check that ~/.ssh on the server is
mode 700 and authorized_keys is mode 600. SSH silently refuses keys in
world-readable files as a security measure.
The "Common gotcha" says SSH "silently refuses keys in world-readable files." What is the practical fix the guide recommends?
Fix the file permissions.
The gotcha states: "check that ~/.ssh on the server is mode 700 and authorized_keys is mode 600. SSH silently refuses keys in world-readable files as a security measure."
Understanding "silently refuses": This is a vocabulary-in-context clue. Silently means no error is shown explaining the real cause — the login just fails or falls back to a password. That is why permission problems are confusing: the symptom (rejected key) does not point to the cause (loose permissions).
Security note for comprehension:
700 = owner read/write/execute only.
600 = owner read/write only.
World-readable means other users on the machine could read your keys — SSH treats that as unsafe and ignores the key.
Option C is a dangerous trap: you never copy a private key to a server — only the public key goes there.
3 / 5
Passage: SSH Key Setup — How-To Guide
Title: How to Set Up SSH Key Authentication for a Remote Server
Prerequisites: You need terminal access on your local machine and an existing way to
log in to the server (usually a password). This guide assumes OpenSSH, which ships with
macOS, Linux, and modern Windows.
Step 1 — Generate a key pair on your LOCAL machine (not the server):
ssh-keygen -t ed25519 -C "you@example.com"
Press Enter to accept the default location (~/.ssh/id_ed25519). You may set a
passphrase for extra security; if you do, you will be prompted for it when the key
is first used in a session.
Step 2 — Copy the PUBLIC key to the server:
ssh-copy-id user@your-server-ip
This appends your public key to ~/.ssh/authorized_keys on the server. You will be
asked for your password one last time.
Step 3 — Test the connection:
ssh user@your-server-ip
If everything worked, you log in without a password (or with only your key
passphrase). Do NOT proceed to Step 4 until this works.
Step 4 — (Optional but recommended) Disable password login on the server:
Edit /etc/ssh/sshd_config and set:
PasswordAuthentication no
Then restart SSH: sudo systemctl restart ssh
WARNING: If your key is not working and you disable password login, you will lock
yourself out. Always confirm Step 3 succeeds first. Keep a second terminal session
open while you test, so you are not relying on a single connection.
Common gotcha: If the server rejects your key, check that ~/.ssh on the server is
mode 700 and authorized_keys is mode 600. SSH silently refuses keys in
world-readable files as a security measure.
Why does the guide suggest you "keep a second terminal session open while you test"?
A safety net against locking yourself out.
The advice appears right after the lock-out warning: "Always confirm Step 3 succeeds first. Keep a second terminal session open while you test, so you are not relying on a single connection."
Reading for the purpose of a precaution: When a guide gives a safety tip, ask "what bad outcome does this prevent?" Here, restarting SSH with a broken config could drop you and refuse new logins. A second, already-open session survives the restart, giving you a way back in to revert the change.
Inference skill: the text says "so you are not relying on a single connection" — you infer the danger (being unable to reconnect) that this guards against. Options A, C, and D invent reasons the text never gives.
Title: Setting Up an Isolated Python Project With a Virtual Environment
Why bother? Installing packages globally with pip leads to conflicts: Project A needs
Django 3, Project B needs Django 4, and they cannot coexist system-wide. A virtual
environment gives each project its own isolated set of packages.
Step 1 — Create the environment (run this inside your project folder):
python -m venv .venv
Step 2 — Activate it. The command differs by platform:
macOS / Linux: source .venv/bin/activate
Windows (PowerShell): .venv\Scripts\Activate.ps1
Your prompt should now show (.venv) at the start. This tells you the environment is
active. Every pip install from now on goes into .venv, not your system Python.
Step 3 — Install dependencies:
pip install -r requirements.txt
Step 4 — When you are finished, deactivate:
deactivate
Important: Do NOT commit the .venv folder to Git — it is large, platform-specific, and
regenerable. Add .venv/ to your .gitignore. Instead, commit requirements.txt so others
(and your future self) can recreate the exact environment with one command.
A note on activation: Activation only affects the current terminal session. If you
open a new terminal, you must activate again. Forgetting to activate is the single
most common cause of "but I installed that package!" confusion.
On Windows (PowerShell), which command does the guide give to activate the virtual environment?
.venv\Scripts\Activate.ps1 — the Windows/PowerShell activation command.
Step 2 lists platform-specific commands: macOS/Linux usessource .venv/bin/activate, while Windows (PowerShell) uses.venv\Scripts\Activate.ps1.
Reading platform-specific instructions: Tutorials often branch by operating system. The skill is matching the right line to your platform — a frequent comprehension trap is grabbing the first command you see (the macOS/Linux one, option B) when you are on Windows.
Why the others fail:
Option A is Step 1 (create, not activate).
Option D is Step 3 (install dependencies).
Option B is the macOS/Linux activation line, not Windows.
Reading carefully means tracking both the step number and the platform label.
Title: Setting Up an Isolated Python Project With a Virtual Environment
Why bother? Installing packages globally with pip leads to conflicts: Project A needs
Django 3, Project B needs Django 4, and they cannot coexist system-wide. A virtual
environment gives each project its own isolated set of packages.
Step 1 — Create the environment (run this inside your project folder):
python -m venv .venv
Step 2 — Activate it. The command differs by platform:
macOS / Linux: source .venv/bin/activate
Windows (PowerShell): .venv\Scripts\Activate.ps1
Your prompt should now show (.venv) at the start. This tells you the environment is
active. Every pip install from now on goes into .venv, not your system Python.
Step 3 — Install dependencies:
pip install -r requirements.txt
Step 4 — When you are finished, deactivate:
deactivate
Important: Do NOT commit the .venv folder to Git — it is large, platform-specific, and
regenerable. Add .venv/ to your .gitignore. Instead, commit requirements.txt so others
(and your future self) can recreate the exact environment with one command.
A note on activation: Activation only affects the current terminal session. If you
open a new terminal, you must activate again. Forgetting to activate is the single
most common cause of "but I installed that package!" confusion.
The guide calls forgetting to activate "the single most common cause of 'but I installed that package!' confusion." What does this tell you about activation?
Activation is per-terminal-session only.
The note states it directly: "Activation only affects the current terminal session. If you open a new terminal, you must activate again." The confusion arises because a package installed in one activated session is invisible in a new, un-activated terminal — hence "but I installed that package!"
Connecting cause to behaviour: This question asks you to read an anecdote (the common confusion) and extract the underlying rule (activation is session-scoped). The symptom only makes sense once you understand the rule.
Why the distractors fail:
Option A reverses it — the whole point of a venv is to avoid changing system Python.
Option C contradicts the guide — every new session needs activation.
Option D ignores the explicit advice to add.venv/ to .gitignore and never commit it.