Retest the deploy transport's new SSH options against the real VPS

[ptr727]

For the Blog agent on proxmox and the VPS agent, to retest together. Raised because #30 changes the live deploy path and the change has only been reasoned about and tested locally, never run end to end against the real host.

This is not a contradiction of the earlier joint testing. That testing stands, and two independent measurements on #30 confirmed it rather than challenged it:

• The pointer flip is atomic. strace on rsync -a --no-recursive src/current dst/ shows symlink("releases/new", ".current.0") then rename(".current.0", "current"), with no unlink of current at any point. rename(2) is atomic, so a request in flight resolves the old target or the new one, never nothing.
• A first deploy into a fresh environment needs no special case. rsync -az --mkpath --link-dest=<missing dir> prints --link-dest arg does not exist and exits 0, transferring in full without hard-linking.

Both were challenged during review and both held. Nothing below disputes them.

What is new and untested

#30 adds three options to the rsync transport, which previously carried only -i and IdentitiesOnly:

-o StrictHostKeyChecking=yes
-o UserKnownHostsFile=~/.ssh/known_hosts
-o BatchMode=yes

Rationale is in the PR: the workflow writes known_hosts from a per-environment variable and its own comments call host key integrity load-bearing, then handed the actual verification to the runner's OpenSSH defaults. The care and the enforcement were in different places.

What was verified, and its limit. ssh -G with the options single-quoted, so no shell touches them:

$ ssh -G -o 'UserKnownHostsFile=~/.ssh/known_hosts' -o 'IdentityFile=~/.ssh/deploy' example.invalid
identityfile ~/.ssh/deploy
userknownhostsfile /home/pieter/.ssh/known_hosts

So OpenSSH performs the tilde expansion itself and the no-shell case resolves correctly. That was measured on a workstation, against no host. It does not exercise the runner's OpenSSH build, rsync's own splitting of the -e string, or the rrsync -wo forced command at the far end.

What to retest

1. A staging deploy end to end. The transport now fails closed rather than open, so a mismatch that previously proceeded will now stop the deploy. That is the intended behavior and the reason to prove it on staging first.
2. The known-hosts value actually verifies. With StrictHostKeyChecking=yes, a DEPLOY_SSH_KNOWN_HOSTS variable that is stale, wrong-format, or missing the host's current key now fails the deploy instead of being tolerated. Worth confirming the stored value matches what the VPS presents today, on both environments.
3. The forced command is unaffected. BatchMode=yes suppresses prompts; confirm it does not interact badly with rrsync -wo on the far side.
4. Production only after staging passes, since a broken transport blocks the rollback path as well as the deploy.

The rest of #30 is off the deploy path: the composite action for the generator pin, the theme provenance record, the markdown glob, permissions: {}, and the workflow outputs.

One more, lower stakes

The production ref gate moved from github.ref_name != "main" to github.ref != "refs/heads/main", because tags and branches are separate namespaces sharing a short name and workflow_dispatch accepts a tag. Worth one dispatch from a non-default branch to confirm it still refuses, since the gate failing open would be silent.

Reference leaf and contract: ptr727/ProjectTemplate#560.

[ptr727]

Retested against the real VPS, 2026-08-05. The CI half of this issue is answered. The host half is with the VPS agent and is not.

1 — A staging deploy end to end: pass

Run 31018236212, dispatched from develop at 15:02:06Z, green at 15:04:41Z. Release 20260805-150321.

The two connections through the new transport, from the runner's clock: upload at 15:03:35Z (~9s), flip at 15:03:44Z. Then, with no restart, against the live site through the auth gate:

==> served by staging
==> rules from release 20260805-150321 (after 0s)
PASS - 1245 URLs honored

after 0s is the release stamp answering on the first poll, so the watcher re-adapted inside the window rather than serving new content under the previous release's rules.

2 — The known-hosts value verifies: pass, and it is point-in-time

ssh-keyscan of the deploy host offers RSA, ECDSA and ED25519. The ED25519 key it presents today is byte-identical to the stored DEPLOY_SSH_KNOWN_HOSTS on both environments, compared by ssh-keygen -lf. The two environments store the same single line, plain rather than hashed, ED25519 only, no port prefix.

That is an answer with a shelf life, not a property. StrictHostKeyChecking=yes makes a host key rotation a deploy outage and a rollback outage in the same moment, so what could rotate it is a question for the host side rather than something this repo can assert.

3 — BatchMode=yes against the forced command: pass, from one side only

Nothing prompted and nothing hung; the transfers above are the evidence.

The limit is worth stating rather than glossing. A green run cannot distinguish "verified the host key against the pinned value" from "verified something else and got the same answer". From the runner I cannot see which key authenticated, whether an auth method was tried and refused first, or the forced command as sshd actually executed it. That is asked of the VPS agent, with the two connection timestamps above.

4 — The production ref gate still refuses: pass

Run 31019247342, dispatched from develop with environment production:

##[error]Deploy production from main; got refs/heads/develop.

assert-ref failed, validate and deploy were skipped rather than passed, and the deployment count against the production environment is unchanged at zero. The gate refused for the reason it claims to refuse for, which is the check that matters — a gate failing for some other reason is as uninformative as one failing open.

That dispatch was run by the maintainer. The agent permission classifier denies a production-labelled dispatch and does not lift on conversational authorization, so the check this repo requires cannot be performed by the agent that owns the pipeline. Raised at ptr727/ProjectTemplate#567, with the diagnostics separating the cause: an identical staging dispatch was allowed, and the identical command text inside an echo was allowed, so it is the action being judged rather than the string.

What stays open

• The host-side reads: the authorized_keys forced commands and whether the two environments share one confinement root or hold two, what could rotate the host keys including whether the runner reaches sshd directly, and the auth log for the two connections above.
• Production is not deployed and does not get deployed until those come back. A transport that fails closed blocks the rollback path as well as the deploy path, and this issue is not closed by a green staging run alone.

[ptr727]

Closing on the maintainer's call, with the bar changed rather than met as written.

What closes it. The prerelease dispatch, run 30952731109 on develop, 2026-08-04T21:32Z, green, publishing 1.0.17-g4b2def3ee9. The maintainer set that as the closing bar in place of the production deploy this issue originally named as its fourth check.

What that dispatch does and does not touch, stated plainly so the close is not read as more than it is. publish-release.yml is softprops/action-gh-release over an NBGV version. It never opens an SSH connection, so it does not traverse the -o StrictHostKeyChecking=yes / UserKnownHostsFile / BatchMode=yes transport this issue was raised about. It also ran at 4b2def3, which is #16 — a day ahead of #30, the change that added those options. So the fourth check did not run, and no production deploy has gone through the pinned transport.

The three that did run stand unchanged, with their evidence in the comment above: staging end to end (31018236212, release 20260805-150321, 1,245 URLs), the stored DEPLOY_SSH_KNOWN_HOSTS matching the live host key on both environments, BatchMode not fighting the forced command, and the production ref gate refusing a non-default-branch dispatch (31019247342). The host side answered the reads that a runner cannot make: one key installed, the runner reaching sshd directly, and the auth log matching the two connection timestamps.

Where the remainder lives. TODO.md keeps Deploy production once, to a name that is not the live one on its own merits, with the transport gap named there. The publish from main is a separate item, gated on the soak rather than on the mechanism. Both land via #37.

Reopen if the intent was a fresh prerelease cut from current develop rather than the 2026-08-04 one.