Automation, rotation, and recovery
Respond to a lost key or host change
Distinguish a compromised user identity from a changed server identity and respond to the right trust boundary.
9 minute lesson
The incident plan records affected accounts, servers, logs, replacement keys, and evidence of unauthorized use. That contrast gives us something useful to test instead of a rule to memorize.
A lost private key requires revoking that public key; an unexpected host key requires stopping and investigating the server path. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.
The happy path can hide a bad design: you can clear warnings and issue new keys without determining which side may be compromised and still get one successful demo. Push past the demo. contain the affected identity, preserve evidence, verify infrastructure through an independent channel, rotate, and monitor, then test the condition most likely to prove the choice wrong.
The module is moving toward one outcome: Operate SSH access over time with narrow automation, regular rotation, revocation, and rehearsed recovery. Save the before-and-after evidence now; it will make the final project review much more honest.
Run tabletop exercises for a stolen laptop and an unexpected host-key warning and compare the actions. Save the evidence, then explain which requirement would force you to choose a different design.
Lesson completed