Change sshd configuration safely

Start from the behavior you can observe. The operator validates the effective daemon configuration, keeps the current session, reloads, and tests a new session before closing anything.

A syntax-valid configuration can still lock you out because keys, users, network policy, or included files behave differently than expected. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to restart the daemon from the only session after several untested changes. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to change one policy, validate it, reload rather than blindly restart, and prove a second login before disconnecting. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Reduce SSH exposure on the server while preserving a tested recovery path before removing existing access. Record enough evidence that another developer can repeat the result without relying on your memory.

Apply a harmless configuration change using the complete safe sequence and record the rollback command. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.