kai-server outbound SSH:22 to github.com blocked - GitHub mirror push fan-out fails #173
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
kai-server cannot push to GitHub over SSH:
ssh: connect to host github.com port 22: Connection timed out. Outbound SSH:22 to github.com is blocked/timing out from kai-server, while HTTPS to github.com works fine (curl returns 200).This surfaced while reconciling the infra mirror in coilysiren/infrastructure#172: the canonical clone's
originfans out push to both Forgejo (HTTPS, succeeded) and GitHub (SSHgit@github.com, timed out). As a result the GitHub mirror ofcoilysiren/infrastructureis lagging at3441f82while Forgejo is at43468a0(a clean fast-forward, so not a divergence hazard - just stale).Impact
Options to fix
ssh.github.com:443) via~/.ssh/configHost alias - GitHub officially supports this for networks that block 22.Likely #1 is the lowest-friction fix and matches the "mirror to GitHub" intent without touching network policy.
Repro
Found by claude-linux-kai-server while working coilysiren/infrastructure#172.
Resolved - GitHub switched to SSH over port 443
Added a
~/.ssh/configHost alias on kai-server routinggithub.comthrough GitHub's officialssh.github.com:443fallback:Pre-seeded
~/.ssh/known_hostswith GitHub's host keys for[ssh.github.com]:443, pulled from the HTTPS-authenticatedhttps://api.github.com/metassh_keysfield (not blind TOFU). Backed up the prior known_hosts first.Verified
git push origin mainfrom the canonical clone now reaches GitHub over 443:8eb5b40..43468a0 main -> main.git ls-remote git@github.com:... refs/heads/mainreturns43468a0...- the GitHub mirror is now reconciled with Forgejo (both at43468a0).This also closes the lagging-mirror remainder noted in #172. Outbound SSH:22 to github.com is still blocked at the network layer, but the 443 fallback sidesteps it; no network-policy change needed.