stage-28 fix: deploy.sh — read-only SSH preflight, no key/known_hosts edits

User asked the script not to touch their SSH config. Reverted the
auto-ssh-keyscan; the script now only READS ~/.ssh/known_hosts (via
ssh-keygen -F) and, when the entry is missing, exits with explicit
manual instructions for verifying the host key and registering an
identity key in Gitea. Identical behavior on the happy path; clearer
diagnostics on the unhappy path; zero modification of ~/.ssh anywhere.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
m17hr1l
2026-05-25 15:39:06 +02:00
parent 2c2ead6149
commit 9edd56e28b

View File

@@ -89,18 +89,24 @@ COMPOSE_PROFILES="${COMPOSE_PROFILES}"
prn() { printf ' · %s\n' "\$*"; } prn() { printf ' · %s\n' "\$*"; }
# 2a. pre-trust the Gitea SSH host key so the first clone doesn't fail with # 2a. preflight: check the Gitea SSH host is trusted (read-only check; we
# 'Host key verification failed'. This is TOFU — we accept whatever the # do NOT modify your ~/.ssh contents — handle host trust yourself once).
# server currently presents. If you want to verify the fingerprint
# manually, do so once and place it in ~/.ssh/known_hosts yourself.
if [[ -n "\$GIT_HOST" ]]; then if [[ -n "\$GIT_HOST" ]]; then
mkdir -p ~/.ssh && chmod 700 ~/.ssh
KH_ENTRY="[\$GIT_HOST]:\$GIT_PORT" KH_ENTRY="[\$GIT_HOST]:\$GIT_PORT"
if ! ssh-keygen -F "\$KH_ENTRY" -f ~/.ssh/known_hosts >/dev/null 2>&1; then if ! ssh-keygen -F "\$KH_ENTRY" -f ~/.ssh/known_hosts >/dev/null 2>&1; then
prn "adding \$KH_ENTRY to ~/.ssh/known_hosts (first time on this prod box)" cat >&2 <<HINT
ssh-keyscan -T 5 -p "\$GIT_PORT" "\$GIT_HOST" 2>/dev/null >> ~/.ssh/known_hosts \ [deploy] STOP — \$KH_ENTRY is not in this user's ~/.ssh/known_hosts on this prod box.
|| { echo "[deploy] could not reach \$GIT_HOST:\$GIT_PORT from this box" >&2; exit 1; } Run these on the prod box ONCE (as the same user that owns \$HOST_PATH), then re-run deploy.sh:
chmod 600 ~/.ssh/known_hosts
ssh -p \$GIT_PORT -T git@\$GIT_HOST
└─ on the fingerprint prompt, verify it matches your Gitea's published key, then type 'yes'
# then sanity-check a clone (will delete itself):
git clone "\$GIT_URL" /tmp/psyc-test && rm -rf /tmp/psyc-test && echo OK
deploy.sh deliberately does not touch your SSH config.
HINT
exit 1
fi fi
fi fi
@@ -110,11 +116,14 @@ if [[ ! -d "\$HOST_PATH/.git" ]]; then
mkdir -p "\$(dirname "\$HOST_PATH")" mkdir -p "\$(dirname "\$HOST_PATH")"
if ! git clone "\$GIT_URL" "\$HOST_PATH"; then if ! git clone "\$GIT_URL" "\$HOST_PATH"; then
cat >&2 <<HINT cat >&2 <<HINT
[deploy] git clone failed. Two likely causes: [deploy] git clone failed. Likely causes (check in order):
This prod box has no SSH key registered in Gitea for this user. Host key wasn't trusted → ssh -p \$GIT_PORT -T git@\$GIT_HOST to accept it once.
Run on prod: cat ~/.ssh/id_*.pub (or ssh-keygen -t ed25519 if none) • No SSH identity key here, or its pubkey isn't in Gitea for this user.
Then in Gitea: Settings → SSH Keys → add it. ls ~/.ssh/id_* 2>/dev/null
• The repo URL is wrong / private and you're not a collaborator. (none?) → ssh-keygen -t ed25519
then: cat ~/.ssh/id_ed25519.pub # paste into Gitea → Settings → SSH Keys
• Repo URL wrong or you're not a collaborator on m17hr1l/psyc.
deploy.sh will NOT modify ~/.ssh — fix it once and re-run.
HINT HINT
exit 1 exit 1
fi fi