Can a GitHub Actions deployment successfully SSH into the wrong server?

[casablanque-code]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Checkout

Discussion Details

I'm thinking about a failure mode in SSH-based deployments.

Kinad DNS points deploy.example.com to a different machine than expected. The new machine accepts SSH connections, credentials are valid, and the deployment proceeds normally.

What actually prevents the deployment from continuing in this case?

Is checking the SSH host fingerprint against a trusted value the right boundary here, or am I missing something?

[Monoartiam99]

What actually stops it: SSH host key verification — comparing the server's host key/fingerprint against a known, trusted value. Credentials only authenticate you to the server; they say nothing about whether the server is the right one. If DNS points somewhere else and that machine accepts valid creds, auth succeeds regardless.

Your instinct is correct — fingerprint checking is the right boundary.

The catch: most CI pipelines defeat this without realizing it via:

• StrictHostKeyChecking no—disables the check entirely
• ssh-keyscan at deploy time fetches the key over the same DNS resolution that could be wrong, so it just trusts whatever's there (fake security)

Fix: pin the host's fingerprint/public key as a secret obtained once out-of-band, populate known_hosts from that pinned value (not ssh-keyscan at runtime), and keep StrictHostKeyChecking yes. Rotate the pinned value deliberately when infra changes.

[casablanque-code]

Exactly. The ssh-keyscan point was the part I was wondering about, it feels like a lot of CI examples establish trust at connection time rather than having an external trust anchor.

I’m particularly interested in whether people actually pin host fingerprints in their deployment workflows, or mostly rely on a managed known_hosts file.

[Monoartiam99]

Very good question; in my experience, the latter is often the case. The most popular CI implementations for SSH keys (like deployer-php-action) set up known_hosts by doing an ssh-keyscan of the host/IP just one time and storing the result as a secret. This is TOFU, not a trust anchor, because the initial scan is not verified independently at all and thus fails to guard against DNS drift.

There is fingerprint pinning (the value is sourced out-of-band—directly on the server itself during a trusted session or from official documentation of the service provider; e.g., GitHub publishes its own SSH key fingerprints), but that is a rarer use case, implemented only by some actions (appleboy/ssh-action implements a dedicated "fingerprint" field for this purpose). It is done mainly by those groups who have carefully considered the MITM attack vector.

Hence, while pinning is the proper solution, the tooling/documentation encourages the managed known_hosts via keyscan, which pretends to be verification.

[casablanque-code]

That matches what I used to see. The interesting part to me is that ssh-keyscan is often presented as the kinda “secure” way to populate known_hosts in CI, even though the initial key acquisition has no independent trust anchor.
Do you think this is mostly an education or documentation problem, or is there a reason fingerprint pinning is awkward enough in CI that people prefer TOFU?

[Monoartiam99]

I also read the many docs and papers. All the papers and documentations are really mature now these days if you get them from a good source.

[justin24er]

Nice question, and yes, SSH host key fingerprint verification is exactly the right boundary here, that's literally what it's designed to prevent. If DNS silently repoints deploy.example.com to a different machine, and that machine happens to accept the same credentials (compromised key, shared secret, misconfigured access, whatever the scenario), SSH host key checking is the only thing standing between "connects successfully" and "connects to the right server."

Here's the mechanism: every SSH server has a host key, and the first time you connect, the client stores that key's fingerprint (usually in known_hosts). On every future connection, SSH compares the presented key against the stored one. If DNS points somewhere else, the new machine will have a different host key (unless the attacker somehow also stole the original server's private host key, a much bigger compromise), so the connection either fails outright or prompts a scary "REMOTE HOST IDENTIFICATION HAS CHANGED" warning.

The catch in CI/CD specifically: many pipelines run with StrictHostKeyChecking=no or auto-accept-on-first-connect to avoid interactive prompts breaking automation, which completely defeats this protection, that's the actual failure mode you're describing. If that flag is set, yes, credentials being valid is all that matters, and a DNS hijack silently succeeds.

Fix: pin the expected host key explicitly in your deploy pipeline (a static known_hosts file checked into the repo or injected via secrets), rather than trusting whatever key shows up on first connect. That way even if DNS is repointed, the mismatched fingerprint hard-fails the job instead of silently deploying to the wrong box.

[casablanque-code]

This is exactly the failure mode I had in mind.

I ended up making a very small GitHub Action around this boundary: it performs the SSH handshake, compares the presented host key against an explicitly pinned fingerprint, and fails the workflow on mismatch.
No ssh-keyscan, no TOFU.

Before deploying, prove u r talking to the right machine. It's kinda motto :)

https://github.com/marketplace/actions/khm-check-fingerprint

Why do u think?

[justin24er]

That's exactly the right approach honestly, no TOFU is the key part, most people miss that. Pinning the fingerprint explicitly and hard-failing on mismatch closes the gap completely. Nice work turning it into a reusable Action too, gonna check it out!