ssh -t git@github.com卡住或报错的直接原因是~/.ssh/known_hosts缺失目标主机公钥指纹且环境无法交互确认，属openssh默认安全行为；需用ssh-keyscan预置密钥并确保权限正确。
直接原因是 SSH 第一次连接目标主机时，~/.ssh/known_hosts 里没有它的公钥指纹，且当前环境无法交互确认（比如 VSCode 后台执行、CI 脚本、Jenkins 构建），SSH 就直接拒绝连接。
为什么 ssh -T git@github.com 会卡住或报错
这不是 Git 的问题，是 OpenSSH 的默认安全行为：它要求用户对未知主机“手动点头”。但很多场景下根本没机会输 yes —— 比如 IDE 自动 fetch、脚本化部署、容器内运行 Git。
- 常见现象：命令行执行
ssh -T git@github.com停在Are you sure you want to continue connecting (yes/no/[fingerprint])?不往下走 - VSCode 集成终端或 Git 图形操作也常静默失败，只报
Host key verification failed - 如果目标主机密钥已变更（如 GitHub 更新了 ED25519 密钥），还会触发
REMOTE HOST IDENTIFICATION HAS CHANGED警告
ssh-keyscan 批量预置可信主机密钥
这是最干净、可复现、适合自动化的方式。它不依赖交互，直接把目标主机当前公开的 SSH 公钥“抓”下来写进 ~/.ssh/known_hosts。
- 对 GitHub 执行：
ssh-keyscan -t ed25519,ecdsa,rsa github.com >> ~/.ssh/known_hosts - 对 Gitee：
ssh-keyscan -t ed25519 gitee.com >> ~/.ssh/known_hosts - 对自建 GitLab（非标准端口）：
ssh-keyscan -t ed25519 [gitlab.example.com]:2222 >> ~/.ssh/known_hosts - 注意：必须用
>>追加，不是>覆盖；否则会清空你已有的其他主机记录
遇到 REMOTE HOST IDENTIFICATION HAS CHANGED 怎么办
说明 ~/.ssh/known_hosts 里存的老密钥和服务器当前发来的不一致。不能硬加，得先清理再重载。
- 删掉旧记录：
ssh-keygen -R github.com（域名）或ssh-keygen -R [192.168.1.100]:2222（IP+端口） - 再跑一次
ssh-keyscan补新密钥 - 验证是否生效：
ssh -T git@github.com应该输出类似Hi username! You've successfully authenticated - 别跳过警告直接禁用校验——尤其在公网环境，
StrictHostKeyChecking no是安全隐患
Jenkins 或 Docker 容器里怎么处理
这类环境通常没有交互终端，且 ~/.ssh 是空的。不能靠手动输 yes，必须提前注入密钥。
- Jenkins：在构建节点上预先运行
ssh-keyscan命令，确保~/.ssh/known_hosts已就位 - Docker：在
Dockerfile中加入 RUN 指令，例如RUN ssh-keyscan -t ed25519 github.com >> /root/.ssh/known_hosts - CI 脚本（GitHub Actions/GitLab CI）：在 job 开头加一步
ssh-keyscan -t ed25519 github.com >> ~/.ssh/known_hosts - Windows WSL2 用户注意：
~/.ssh/known_hosts路径有效，但权限必须是 600（chmod 600 ~/.ssh/known_hosts），否则 SSH 会忽略它
真正容易被忽略的是密钥类型和端口组合——比如只扫了 ed25519，但服务器只支持 ecdsa，或者用了非 22 端口却没在 ssh-keyscan 里指定，照样失败。动手前先确认目标服务实际支持哪些密钥算法和端口。
