ops: unlock cortex-production SSH via GHA

[echobt]

Hardcode cortex-production IP; disable host ufw that still drops :22. PROD_HOST secret still points at legacy base-prod.

[greptile-apps]

Greptile Summary

This workflow adds fixed production and staging SSH targets. On the production UFW path, it disables the host firewall after allowing SSH, so the change should not merge until UFW remains enabled and SSH access is narrowed to the required rule.

Confidence Score: 3/5

Not safe to merge until the production workflow stops disabling the host firewall.

The executed check confirmed that the production SSH path disables UFW after adding SSH rules, leaving other listening services without host-level ingress filtering.

Files Needing Attention: .github/workflows/ops-box-ssh-access.yml

Security Review

The production SSH-access workflow disables UFW globally. This removes host-level ingress filtering for all listening services rather than only restoring SSH access.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for a posted P1 finding and linked to the review comment.
• T-Rex produced a proof for a second posted P1 finding.
• T-Rex performed a sandboxed contract validation by running the before and after firewall-simulation scripts, both exited with code 0, and the after state showed the expected ufw changes before a final disable; live production access was not attempted for safety.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Workflow disables UFW entirely on hard-coded production host

   • Bug
     • The SSH injection step assigns cortex-production|root@165.227.91.243|ufw. In the ufw branch, after adding SSH allow rules, it always runs ufw --force disable || true. This disables UFW globally rather than narrowly restoring SSH access, leaving any host service that is reachable through the cloud perimeter without UFW ingress filtering.
   • Cause
     • The ufw conditional groups SSH recovery commands with a global firewall-disable command and has no condition, restoration step, or scoped rule change around ufw --force disable.
   • Fix
     • Remove ufw --force disable || true. Preserve or enable UFW and add only the needed temporary SSH rule (ideally restricted to the runner IP), then remove that rule after access is complete; do not use a global firewall disable as SSH recovery.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "ops: also unlock cortex-production SSH (..." | Re-trigger Greptile}

[greptile-apps]

Do Not Disable UFW

The production target enters the ufw branch, adds SSH allow rules, and then unconditionally disables UFW for the entire host. This removes host-level ingress filtering for every listening service, not just SSH, so services reachable through the cloud perimeter can be exposed without the host firewall protection.

Keep UFW enabled and use a narrowly scoped SSH rule instead. Remove the global disable command.

How this was verified: A controlled execution of the checked-in UFW branch showed SSH rules are added and UFW is then changed from enabled to disabled.

Artifacts

Evidence from the check

• Authored executable validation source mocks UFW and iptables, checks the exact workflow markers, and asserts that the UFW branch disables UFW after SSH rules, proving the command path safely.

Command output from the check

• Executed pre-command capture records cortex-production's UFW-mode state as enabled without using credentials, network access, or live firewall commands, establishing the comparison baseline.

Command output from the check

• Executed simulation trace records both SSH allow commands followed by `ufw --force disable` and ends with simulated UFW disabled, confirming the global disable occurs unconditionally.

_{Ran code and verified through T-Rex}