Pin host keys via variables instead of ssh-keyscan

Replaces the ssh-keyscan-based known_hosts population (and the
diagnostic step added to debug its flakiness) with two vars,
GITEA_HOST_KEY and DEPLOY_HOST_KEY, each a full known_hosts-format
line. No extra network calls before the real connections, no TOFU, and
no more risk of tripping aquaria's connection-rate limiting — the
actual root cause of the earlier flakiness was ssh-keyscan opening
multiple near-simultaneous connections (one per probed key type).

.gitea/workflows/build-deploy.yml

@@ -13,45 +13,30 @@ jobs:
       - name: Install system dependencies
         run: |
           apt-get update
-          apt-get install -y --no-install-recommends git rsync openssh-client nodejs netcat-openbsd dnsutils
+          apt-get install -y --no-install-recommends git rsync openssh-client nodejs
 
       - name: Checkout
         uses: actions/checkout@v4
         with:
           submodules: false
 
-      # Temporary diagnostic step — remove once the aquaria connectivity
+      - name: Set up SSH key and pinned host keys
-      # issue is root-caused. ssh-keyscan swallows pre-handshake failures
-      # even with -v, so this checks DNS + raw TCP connect independently.
-      - name: Diagnose connectivity to deploy host
-        env:
-          DEPLOY_HOST: ${{ vars.DEPLOY_HOST }}
-          DEPLOY_PORT: ${{ vars.DEPLOY_PORT }}
-        run: |
-          echo "--- DNS resolution ---"
-          getent hosts "$DEPLOY_HOST" || echo "getent: no result"
-          dig +short A "$DEPLOY_HOST" || true
-          dig +short AAAA "$DEPLOY_HOST" || true
-          echo "--- TCP connect (IPv4) ---"
-          nc -4 -zv -w 8 "$DEPLOY_HOST" "${DEPLOY_PORT:-22}" || echo "nc exit code: $?"
-
-      - name: Set up SSH key
         # Same key used both as the theme repo's deploy key (Gitea) and for
         # the webserver login (below) — one secret, two authorized_keys entries.
+        # Host keys are pinned via vars (each a full known_hosts-format line,
+        # e.g. from the server's own /etc/ssh/ssh_host_rsa_key.pub) rather
+        # than fetched via ssh-keyscan — no extra network calls, no TOFU, and
+        # no risk of tripping aquaria's connection-rate limiting.
         env:
           DEPLOY_SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
-          DEPLOY_HOST: ${{ vars.DEPLOY_HOST }}
+          GITEA_HOST_KEY: ${{ vars.GITEA_HOST_KEY }}
-          DEPLOY_PORT: ${{ vars.DEPLOY_PORT }}
+          DEPLOY_HOST_KEY: ${{ vars.DEPLOY_HOST_KEY }}
         run: |
           mkdir -p ~/.ssh
           printf '%s\n' "$DEPLOY_SSH_KEY" > ~/.ssh/deploy_key
           chmod 600 ~/.ssh/deploy_key
-          # -t rsa: both hosts confirmed to offer an RSA host key. Restricting
+          printf '%s\n' "$GITEA_HOST_KEY" >> ~/.ssh/known_hosts
-          # to one type means one connection per host instead of ~4 fired at
+          printf '%s\n' "$DEPLOY_HOST_KEY" >> ~/.ssh/known_hosts
-          # once (one per probed key type), which aquaria's connection-rate
-          # limiting was intermittently dropping past the first.
-          ssh-keyscan -4 -t rsa -H git.haemka.in >> ~/.ssh/known_hosts
-          ssh-keyscan -4 -t rsa -H -p "${DEPLOY_PORT:-22}" "$DEPLOY_HOST" >> ~/.ssh/known_hosts
 
       - name: Fetch theme submodule
         run: |