SSH keys and access recovery

SSH verifies two identities

The server proves its host identity to the client; the client then authenticates as an account. A trusted host-key fingerprint and your personal login key solve different problems. Do not suppress host verification just to remove an unfamiliar warning.

For a disposable VM with OpenSSH already enabled, record the VM address, account, SSH port, and console recovery method. Obtain its host-key fingerprint through the VM console or another trusted channel before accepting a first connection.

Separate connection, host trust, and login

An SSH client first reaches the configured server and negotiates an encrypted connection. The server's host key lets the client recognize that server. A first-connection prompt needs a fingerprint obtained through a trusted route, not a guess based on the hostname. A later mismatch can mean a rebuild or an unexpected endpoint and must be investigated.

Your user key proves that you hold a private key corresponding to an authorized public key. The private key stays on your client; the public part can be installed in the intended server account's authorized_keys. It is not a password to paste into the server. A passphrase protects the private-key file at rest; an SSH agent can hold an unlocked key for use without repeatedly typing that passphrase.

Do not confuse the two username conventions in this path. For ordinary ssh USER@VM_ADDRESS, USER is a guest account. For OrbStack's built-in ssh sk-foundations@orb, the part before @orb selects a machine according to OrbStack's integration. That route is not proof that a guest OpenSSH daemon is configured. Use the core access lab for OrbStack; the following dedicated-key practice needs a separate guest OpenSSH endpoint with known console recovery.

Use a dedicated lab key

Choose a new filename that does not already exist and generate it on the client:

ssh-keygen -t ed25519 -f "$HOME/.ssh/learnwithsk_lab_ed25519" -C 'learnwithsk-local-lab'

Use a passphrase. Keep the private file private; only the .pub content goes into the VM account's ~/.ssh/authorized_keys. If the filename already exists, select another; do not overwrite it. The directory and file must have suitable ownership and restrictive modes, typically 700 and 600 respectively for a user-owned setup.

Replace the address and username with your real lab values:

ssh -o IdentitiesOnly=yes -i "$HOME/.ssh/learnwithsk_lab_ed25519" USER@VM_ADDRESS

Confirm id and hostname inside the session. Keep the console and original session open while checking a second login.

Install only the public part in the intended account

On a guest OpenSSH server where you already have console access, log into the intended regular account. Inspect whether ~/.ssh and authorized_keys already exist; preserve their entries. Create the directory if needed with mkdir -p ~/.ssh, apply chmod 700 ~/.ssh, and use an editor to append the single public-key line from the client's .pub file. Do not paste the private file, and do not replace existing lines. Use chmod 600 ~/.ssh/authorized_keys and check that both paths belong to the intended account.

Then run the preceding client command with your actual user/address. The server decides whether the key, account, permissions, and effective configuration allow login. The client option IdentitiesOnly=yes restricts which identities it offers for this connection; it does not bypass server checks.

For an unsuccessful attempt, classify the stage:

Use ssh -v with this disposable setup for negotiation clues if needed. Treat its paths and metadata as private until reviewed. A second successful session while keeping the first open is stronger evidence than merely generating a key.

Recover deliberately

Before any server configuration change, validate syntax with the installed sshd -t command as administrator, check effective configuration and applicable Match rules, and identify the distribution's service/socket activation setup. Only disable a previous login method after the replacement has been tested. A changed host key requires investigation; rebuilding the VM is one legitimate explanation, but not the only one.

Disabling password login, restricting allowed groups, changing firewall rules, and setting up a bastion are optional server-hardening work. Each can affect recovery and depends on the actual service/socket arrangement. Do not copy a blanket hardening file into OrbStack to complete the foundations lab.

Self-check: which key detects an unexpected server, and which key authenticates your account? The server host key establishes server identity; your user key participates in account authentication. A valid host key does not grant you an account, and an authorized user key does not remove the need to check the host.

Check and revise

Cleanup means remove this lab's public-key line from the VM and then retire its dedicated client key if no longer needed. Preserve unrelated keys. Revision: trusted host → intended account → scoped key → tested second session → documented console recovery.

Sources

Primary references: Ubuntu OpenSSH↗; OpenSSH client↗; Key generation↗.