Install and restrict public keys

A deployment identity can run one controlled command without receiving an unrestricted interactive shell. That contrast gives us something useful to test instead of a rule to memorize.

authorized_keys grants login capability to a user account and can constrain source addresses, commands, forwarding, or other features. 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 paste private material onto the server or append keys without knowing which account owns the file and still get one successful demo. Push past the demo. install only the public line, set correct ownership and modes, and add restrictions for narrow automation identities, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Create a maintainable client identity setup without copying private keys or making authentication implicit. Save the before-and-after evidence now; it will make the final project review much more honest.

Create a restricted test key and verify both the allowed operation and a denied interactive shell. Save the evidence, then explain which requirement would force you to choose a different design.