Lab: document SSH access and a recovery path

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.

Sources

Primary references: OrbStack SSH↗; OpenSSH client↗; Ubuntu SSH server↗.