Practical lab guide
Lab: document SSH access and a recovery path
Distinguish OrbStack transport from guest OpenSSH administration.
Linux
Predict before you try
Answer before proceeding: did this test exercise a separately configured guest /etc/ssh/sshd_config?
Try it: Practice guest-managed SSH only where available →On this page
Choose the access boundary
OrbStack's built-in SSH access is useful for later Ansible work. From the Mac, inspect the orb host configuration with ssh -G orb and connect to the named machine using ssh sk-foundations@orb. Confirm id and hostname there.
This verifies OrbStack-managed access. Editing a guest's /etc/ssh/sshd_config does not configure OrbStack's built-in SSH server. Record which of these two access paths you tested.
Read what the core OrbStack test established
ssh -G orb prints the effective client configuration without opening a session. Inspect hostname, port, user, and identityfile fields locally; do not copy private key contents. Then ssh sk-foundations@orb uses OrbStack's integration to select the named machine. id confirms the resulting Linux account, and hostname helps distinguish it from another machine.
Exit the SSH session, then from the Mac open the same machine with orb -m sk-foundations and compare id and a harmless known file such as ~/foundations-notes/environment.txt. This provides an alternate management entry path for the core fixture. Both depend on OrbStack and the Mac, so it is not a disaster-recovery route for a lost host.
Answer before proceeding: did this test exercise a separately configured guest /etc/ssh/sshd_config? No. It demonstrated OrbStack-managed transport into the machine. Completing this core route is enough for the path; the guest-daemon exercise below is optional and must be labeled separately.
Practice guest-managed SSH only where available
For the separate OpenSSH-key exercise, use a disposable Linux VM or a deliberately installed guest OpenSSH service with a known address and console access. Follow the preceding key bite: dedicated client key, trusted server fingerprint, public key in the intended guest account, and a tested second session.
Record the server's actual service/socket setup before any change. Keep the original session and console available. Validate any configuration with sshd -t; inspect effective settings and applicable match rules. This exercise does not require disabling password login or changing a shared server.
Build the access runbook
Record the client, transport endpoint, target user, authentication method, host-key verification channel, and recovery method. For a denied login, distinguish unreachable endpoint, unexpected host identity, rejected key/account, and a post-login command permission error.
Rehearse recovery by using the independent console to inspect the lab key entry while leaving working access intact. Do not intentionally lock yourself out to prove the recovery plan exists.
Cleanup and checkpoint
Remove only a dedicated lab public-key entry and client key when retiring them. Do not delete OrbStack's generated integration key or edit global SSH configuration as cleanup. Retain the named machine for later modules.
Explain what ssh sk-foundations@orb established and what remains untested about a guest OpenSSH daemon. Explain why the same command succeeding as root does not prove a restricted user's access.
Revision: transport identity → server trust → account authentication → command authorization → independent recovery. Mark completion only after recording the access path you actually tested; a documented alternative is not an executed result.
Apply this to MicroBank
Put the tested SSH route and alternate OrbStack entry route in the MicroBank readiness runbook. Both rely on the same Mac and OrbStack installation. State that shared dependency and the actual identity reached. This is access recovery for the learning machine; restoring a lost platform host or application data remains a separate task.
Keep this observation in the MicroBank readiness project.
Sources
Primary references: OrbStack SSH↗; OpenSSH client↗; Ubuntu SSH server↗.
Prove what you learned
Inspect the result
Retain identity, scoped access evidence and a documented recovery path without private keys.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Change the intended identity in a paper case and identify which evidence must be collected again.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Practice guest-managed SSH only where available”.
- Retain identity, scoped access evidence and a documented recovery path without private keys.
- Explain the transfer challenge and retain the same verification question.
Hint
Separate transport, host trust, user authentication and command authorization.
Answer guide: compare after predicting
No. It demonstrated OrbStack-managed transport into the machine. Completing this core route is enough for the path; the guest-daemon exercise below is optional and must be labeled separately.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall effective permissions and parent-directory traversal. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.