Skip to content
Community

EXPLORE TOPICS

Editorial approach

New to CoreTrailKit?

Observe your services. Keep the evidence close.

CoreTrailKit
Back to articles
GUIDE/ SSH

Review an SSH profile before connecting

An SSH alias is a set of resolved configuration values, not just a short hostname. Review those values locally before attributing a failed login to the server.

By CoreTrailKit3 min read

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.

text · EXAMPLE
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 3

02

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.

bash · EXAMPLE
ssh -G -F ./ssh-demo.conf demo-staging

03

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.

bash · EXAMPLE
ssh -G -F ./ssh-demo.conf -l reviewer demo-staging

05

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

CONTINUE EXPLORING