Automation, rotation, and recovery
Build narrow automation
Give deployment jobs a dedicated identity, known host, restricted command, and minimal server permissions.
9 minute lesson
Before choosing a tool or writing more code, make the requirement concrete. The deploy key can invoke one server-side release script and cannot open a shell or forward ports.
Noninteractive SSH removes a human checkpoint, so its allowed action and failure behavior must be narrower and more observable. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.
A common failure is to reuse a personal administrator key in CI and disable host checking to make it work. The happy path may still work, which makes the mistake easy to miss. create a dedicated identity, pin the host, restrict authorized_keys, scope server permissions, and log every run. Keep the first version small enough that every important input and output remains visible.
This supports the module goal: Operate SSH access over time with narrow automation, regular rotation, revocation, and rehearsed recovery. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.
Run the allowed deployment and attempt a shell, arbitrary command, and tunnel; only the intended action should work. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.
Lesson completed