Skip to main content
FDEs often need private Gitea repos and one or more clean-room Linux workstations/LXCs. Treat access as permissioned infrastructure, not as a shortcut around the platform.

​
Generate or locate your SSH key

ls -la ~/.ssh/*.pub 2>/dev/null || true
ssh-keygen -t ed25519 -C "<your-company-email-or-identity>" -f ~/.ssh/id_ed25519 -N ""
cat ~/.ssh/id_ed25519.pub
Paste only the public key into the internal Gitea/access UI. Never paste private keys, tokens, credential-helper contents, or raw enrollment codes.

​
Verify Gitea source access

tea login list
tea whoami
git ls-remote <private-khal-gitea-repo-url>
Successful shape: 
Logged in to <gitea-host> as <username>
<sha>	HEAD
<sha>	refs/heads/dev

​
Verify SSH/LXC access

Use the alias or host returned by the onboarding plan: 
ssh <fde-lxc-alias> 'hostname; whoami; pwd; git --version; command -v khaw || true; command -v khal || true'
Expected transcript shape: 
fde-caio-lxc
caio
/home/caio
git version 2.x.x
/home/caio/.local/bin/khaw
/home/caio/.local/bin/khal
If the alias is missing, do not guess private IPs. Ask KHAW to inspect the onboarding plan and produce an access request.

​
KHAW SSH helper

When KHAW auth is available, preview the SSH action without connecting: 
khaw ssh <identity> --hostname <fde-lxc-alias> --dry-run
The output should show the authorized route and final SSH command with mutation: none. 
TASK: I am reading `fde-start-here/ssh-access.mdx` (SSH, Gitea, and LXC access). Use this page as the contract, then verify current CLI/output before you guide me.
CONTEXT: I may be a new KHAL FDE. Prefer read-only checks and dry-runs first. Do not mutate customer, HML, production, credentials, SSH, Gitea, or model-provider state without an explicit GO.
SAFE FIRST COMMANDS: Check versions, identity, target, git source/ref, KHAW doctor/status, KHAL context, and dry-run output. Redact secrets and private URLs.
EVIDENCE: Return command, exit status, sanitized output, what it proves, and the next safe action.