01
1. Use a disposable trusted configuration
Create a new working folder and save this example as ssh-demo.conf. Its hostname uses the reserved .invalid suffix, and its identity filename is a placeholder. Neither a real key nor a server is required for this local exercise.
The specific host block comes before the wildcard defaults. Some options accumulate rather than behaving like scalar defaults, so inspect the resulting IdentityFile entries instead of assuming one filename must be the entire identity list.
Host demo-staging
HostName staging.example.invalid
User observer
Port 2222
IdentityFile ~/.ssh/demo_staging_ed25519
IdentitiesOnly yes
StrictHostKeyChecking yes
ForwardAgent no
Host *
ServerAliveInterval 30
ServerAliveCountMax 302
2. Resolve the alias without a login attempt
Run the command below from that folder. -F selects the demo configuration and -G prints the configuration after evaluating Host and Match rules rather than opening the SSH session.
Only evaluate configuration you trust. This example contains no Include, Match exec or canonicalization rules. A real configuration may have local evaluation behavior that deserves review before treating the inspection as inert.
ssh -G -F ./ssh-demo.conf demo-staging03
3. Check the destination and account
Find hostname, user and port in the output. For this example, they should resolve to staging.example.invalid, observer and 2222. A configured alias can resolve to a different destination than its friendly name suggests.
Next check identityfile, identitiesonly, stricthostkeychecking and forwardagent. The example requests explicit identity selection, strict host-key checking and no agent forwarding. Printed paths and usernames are configuration information; do not paste a full private profile into a public issue.
04
4. Check an intentional override
Compare the user value with this second command. The command-line override should resolve to reviewer without changing ssh-demo.conf. This is a useful way to distinguish a one-off invocation from a persistent profile edit.
ssh -G -F ./ssh-demo.conf -l reviewer demo-staging05
5. Keep the conclusion within the evidence
The inspection confirms how the client resolves these settings. It does not prove the server exists, the selected key file exists, the account is authorized or the server fingerprint is trusted. Those are later checks in your normal access workflow.
For a real host, verify the fingerprint through a trusted channel and keep the intended host-key policy. Do not disable that policy just because a dry inspection succeeded. No change to the user’s real SSH configuration is needed to complete this lab.
06
Verification boundary
The editorial test ran OpenSSH -G against this isolated file, checked the resolved destination, account, port and policies, and verified the command-line user override. It also confirmed that the file was unchanged. No SSH connection or authentication attempt was made.
Know the limits
ssh -G does not authenticate to a server. Use trusted configurations: evaluating Match exec can run a local command even during configuration inspection.
Sources & further reading
A technical publication by CoreTrailKit.
Browse all articles