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