Reduce authentication and network exposure

Password login and direct root login are disabled after personal key access and provider-console recovery are tested. That contrast gives us something useful to test instead of a rule to memorize.

Hardening removes unnecessary paths only after a working replacement and recovery channel are proven. 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 disable methods from a checklist before verifying keys, console access, and automation dependencies and still get one successful demo. Push past the demo. inventory users and clients, prove key access and recovery, then remove unused authentication and network exposure, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Reduce SSH exposure on the server while preserving a tested recovery path before removing existing access. Save the before-and-after evidence now; it will make the final project review much more honest.

Test allowed and denied users, password attempts, root attempts, and a firewall rule from a separate session. Save the evidence, then explain which requirement would force you to choose a different design.