Small SSH server configuration review

# Small SSH server configuration review

Review a deliberately small SSH server configuration against a fictional explicit baseline and notice first-value precedence and access-route gaps.

This is an original, fictional, offline exercise for an introductory security learner. It is independent practice, not copied coursework or a claim of professional experience. Completion and competence remain unassessed.

## Before you start

Allow **30-45 minutes**: 5 minutes reading, 10 inspecting and predicting, 10 checking and explaining, and 5-20 for a changed or independent case. You need Python 3.10+ (standard library only), a terminal and a text editor. Comfort opening files, reading a small table and basic evidence notes is enough; programming, administrator rights, a Linux installation and cloud accounts are unnecessary. Previous introductory network or Wireshark practice is useful but not required.

> **Vocabulary:** sshd: the SSH server. Directive: a configuration keyword/value. Public-key authentication: a method using possession of a private key, with server authorisation also required. Keyboard-interactive: an authentication mechanism distinct from PasswordAuthentication. Precedence: which repeated value takes effect.

## Evidence and exact rules

The case JSON is the single authoritative input. Fixtures are guided.json, changed.json and challenge.json. All data is synthetic; artifacts is empty to avoid competing editable copies. Edit only a prepared run copy. The analyser is a pure calculation and never executes evidence text.

data.config is the authoritative raw configuration text. The only supported directives are PermitRootLogin, PasswordAuthentication, KbdInteractiveAuthentication, PubkeyAuthentication, PermitEmptyPasswords and MaxAuthTries. Keywords are case-insensitive; values are case-sensitive. Lines must be one plain keyword and value, with empty lines and whole-line # comments allowed. Quoting, inline comments, Match, Include, unknown directives and other complex syntax are rejected. This is deliberately narrower than sshd_config.

For supported directives, first occurrence wins and later occurrences are reported as ignored. The fictional baseline is root/password/keyboard-interactive/empty-password settings no, public-key setting yes, and MaxAuthTries 1-4. MaxAuthTries accepts 1-100 for comparison. Each setting is matches-lab-baseline, differs-from-lab-baseline or missing-explicit-setting. No missing default is guessed. access-route is insufficient-explicit-method-settings when any of the three authentication settings is missing; otherwise public-key-method-enabled if keys are enabled, alternative-method-enabled if only another supported method is enabled, or no-supported-method-enabled if all three are off.

## Run the exercise

Open a terminal in this lab folder. Use your Python command (`python`, or `py -3` if that is how Python is installed). Commands below use `python` consistently.

```text
python lab.py cases
python lab.py prepare --scenario guided --out run/attempt-01
python lab.py show --case run/attempt-01/case.json
```

Read the evidence. In run/attempt-01/answers.json, fill each decision with an exact label from the rules; add an explanation and evidence references such as record IDs or configuration line numbers. In notes.txt, separate observation, interpretation, uncertainty, next check and help used. Save your prediction before opening the answer.

```text
python lab.py analyse --case run/attempt-01/case.json
python lab.py check --case run/attempt-01/case.json --answers run/attempt-01/answers.json
python lab.py prepare --scenario changed --out run/attempt-02
python lab.py prepare --scenario challenge --out run/attempt-03
python -m unittest -v test_lab.py
python lab.py verify
```

For changed/challenge use the corresponding attempt folder in show/analyse/check. prepare refuses an existing output folder. --out is relative to this lab and must be below run/; explicit input paths are relative to your terminal directory. analyse/show default to the guided fixture if --case is omitted. Exit 0 means command success or decision match; 1 means differences/incomplete written fields; 2 means invalid input or a filesystem problem. The checker verifies decision fields and the presence of writing, not the quality of reasoning. verify checks shipped examples, not learner mastery.

## Deliverable and limits

Keep case.json, answers.json and notes.txt together in the ignored run folder. Deliver a short handover: the question, your conclusion, two precise evidence references, one alternative explanation or limitation, and the next evidence you would request. State whether you used the worked example and whether you completed a fresh case unaided. Do not describe an automated match as assessment or professional experience.

Only six explicit directives are modelled. Missing settings are unknown here; no version-specific defaults are assumed. Match, Include, unknown directives and complex syntax are rejected. First occurrence wins for these supported directives. This text review is not sshd validation and cannot establish keys, PAM behaviour, network exposure or a working recovery login. No host configuration was read or changed.

Use WORKED-EXAMPLE.md after making a first prediction, and DRILLS.md for progressively less support. Do not use these rules as an operational security verdict or modify a real host as part of this exercise.

## Primary references

The following documentation supports the underlying concepts; the tiny schema and explicit teaching rules above are specific to this lab. Links were checked during authoring on 23 October 2026. Running the lab needs no internet connection.

- [OpenSSH sshd_config manual](https://man.openbsd.org/sshd_config)

# Worked example: Small SSH server configuration review

Try the guided case before reading this page. Use `python lab.py prepare --scenario guided --out run/worked-01` if you need a fresh ignored copy.

The guided text has PermitRootLogin prohibit-password. This still permits some root authentication methods, so it differs from the lab requirement no. PasswordAuthentication yes also differs. Keyboard-interactive no, public keys yes, empty passwords no and MaxAuthTries 4 match. access-route says public-key-method-enabled because that method is explicitly enabled; it does not say that a working key or recovery login exists. The exercise never loads host configuration or starts a server.

The reference decision fields for guided are:

```json
{
  "permitrootlogin": "differs-from-lab-baseline",
  "passwordauthentication": "differs-from-lab-baseline",
  "kbdinteractiveauthentication": "matches-lab-baseline",
  "pubkeyauthentication": "matches-lab-baseline",
  "permitemptypasswords": "matches-lab-baseline",
  "maxauthtries": "matches-lab-baseline",
  "access-route": "public-key-method-enabled"
}
```

Now open `python lab.py analyse --case run/worked-01/case.json` and compare observations, not only labels. Record one difference between your first prediction and the reference. If there was no difference, explain the rule that produced each decision rather than copying the label.

Handover prompt: explain what this evidence establishes, cite its exact IDs or lines, give a plausible alternative or remaining uncertainty, and name the smallest next check. Record any help used. A correct label by itself is not evidence of independent understanding.

# Drills: Small SSH server configuration review

## Guided practice

Prepare guided in a fresh run folder, read the README rules, and make a prediction for every decision ID. Use WORKED-EXAMPLE.md only after saving that prediction. Correct your explanation in a different paragraph so the original reasoning remains visible.

## Prompts only

Close the worked example and use these questions to reconsider the evidence:

- Why does prohibit-password differ from no for root login?
- Can PasswordAuthentication no alone establish that every password-like authentication route is disabled?

## Independent attempt

Prepare challenge in a fresh folder. Keep reference outputs, worked example and analyse closed until you have saved answers.json plus a five-sentence handover in notes.txt. Include the observation, interpretation, an alternative, uncertainty and next check. Use the README for syntax if needed and record that help. Afterwards run analyse/check and have a person inspect the explanation. Independent completion is unassessed unless someone actually reviews it.

## Changed case

Prepare changed. Predict which conclusions change and which do not. Explain the changed evidence before checking:

- Which changes make the six explicit settings match the fictional baseline?
- Why does matching this baseline still not prove that a login works or the server is secure?

Small edit drill: In a copied challenge case, move PermitRootLogin no before PermitRootLogin yes. Predict the root-setting result and explain why the authentication-route gap remains.

## Teach-back

Explain first-value precedence and why an unsupported Match or Include must stop this small reviewer rather than be ignored. Use exact record IDs from your attempt. A partner should ask one counterexample rather than accepting a memorised label. Record the question and your response.

## Later recall

After 24-72 hours, reopen only your own notes and a fresh case. Write the central rule from memory, identify one boundary or missing-evidence condition and predict the result. Then check the documentation and record what you forgot. Do not count rereading an answer as an independent attempt.

## Handover

Keep the copied case, completed worksheet and notes together. State the scope, conclusion, two evidence references, unresolved uncertainty and requested next check. Include help used and whether someone assessed the reasoning. Do not claim experience beyond this fictional exercise.