fix(security): E2E test scripts still use StrictHostKeyChecking=no

[cjagwani]

Summary

PR #691 hardened the deploy() path to use SSH TOFU (trust-on-first-use) with pinned host keys. However, ~25 instances of StrictHostKeyChecking=no remain in E2E test scripts:

• test/e2e/brev-e2e.test.js
• test/e2e/test-full-e2e.sh
• test/e2e/test-credential-sanitization.sh
• test/e2e/test-telegram-injection.sh
• test/e2e/test-messaging-providers.sh
• test/e2e/test-gpu-e2e.sh
• test/e2e/test-sandbox-survival.sh
• test/e2e/test-e2e-cloud-experimental.sh
• test/e2e/e2e-cloud-experimental/ (multiple scripts)

These are test scripts SSHing into freshly provisioned Brev VMs, so the risk is lower than the deploy path (no secrets in transit during most test commands). But for consistency and defense-in-depth, they should use the same TOFU pattern.

Proposed fix

Extract a shared SSH TOFU helper (e.g., test/e2e/lib/ssh-tofu.sh) that the test scripts source, similar to how deploy.ts now handles it.

Related

• fix(security): pin SSH host keys via trust-on-first-use instead of StrictHostKeyChecking=no #691 — deploy path SSH hardening

[harsh-labz]

An MVP fix could swap all StrictHostKeyChecking=no calls with a shared SSH‑TOFU helper to match the secure deploy flow. Happy to collaborate on this if assigned.

[wscurran]

This was fixed in #691 — E2E deploy scripts now use a trust-on-first-use (TOFU) pattern: the initial connectivity probe accepts the host key, then ssh-keyscan pins it to a temp known_hosts file. All subsequent connections (including SCP of secrets) use StrictHostKeyChecking=yes against the pinned key. Closing as resolved.