SSH密钥问题需分步排查：先验证密钥存在且已加载，再测试SSH连通性，检查Git配置与composer.json中仓库URL类型是否匹配，并确认~/.ssh/config中Host配置准确无误。
确认 SSH 密钥是否已正确生成并加载
这个错误通常不是 Composer 本身的问题，而是 Git 在尝试通过 SSH 克隆私有仓库（比如 GitHub、GitLab 或自建 Git 服务器）时失败。第一步必须验证本地 SSH 密钥状态。
- 运行
ssh-keygen -l -f ~/.ssh/id_rsa确认密钥存在且可读；若提示“No such file”，需先用ssh-keygen -t ed25519 -C "your_email@example.com"生成 - 执行
ssh-add -l检查密钥是否已载入 agent；若无输出，运行ssh-add ~/.ssh/id_rsa（或对应私钥路径） - 某些系统（如 macOS Catalina+）默认不自动启动 ssh-agent，需手动启用或配置
~/.zshrc加入eval "$(ssh-agent -s)"
测试 SSH 连通性与权限是否匹配
Composer 调用的是系统 Git，Git 调用的是 SSH，所以必须能直接用 SSH 访问目标仓库地址。不能只依赖 HTTPS 配置或网页登录状态。
- 用 Git 托管平台提供的测试命令验证：例如 GitHub 是
ssh -T git@github.com，GitLab 是ssh -T git@gitlab.com - 如果返回
Permission denied (publickey)，说明密钥未被接受——常见原因是公钥没添加到对应账户的 SSH Keys 设置页，或添加时多粘贴了空格/换行 - 注意区分
git@github.com:vendor/package.git和https://github.com/vendor/package.git；Composer 默认优先走 SSH，除非你在composer.json中显式指定"url": "https://..."
检查 Composer 的 Git 配置与仓库 URL 类型
Composer 会读取全局或项目级 Git 配置，并可能根据 composer.json 中的 repositories 定义覆盖默认行为。错误常出现在混合使用 HTTPS 和 SSH 场景中。
- 运行
git config --global url."https://".insteadOf git://是常见优化，但它也可能干扰私有 SSH 仓库——确认没有误配git@域名为https:// - 检查
composer.json中是否定义了自定义仓库，例如：{ "repositories": [ { "type": "vcs", "url": "git@github.com:myorg/private-package.git" } ] }确保该 URL 可被本地 SSH 正确解析 - 临时切换为 HTTPS 测试是否是 SSH 环境问题：把
git@github.com:myorg/pkg.git改成https://github.com/myorg/pkg.git，再运行composer update；若成功，问题就锁定在 SSH 环境
排查 SSH 配置文件（config）中的 Host 别名冲突
很多人为了管理多个 Git 账户，在 ~/.ssh/config 中设置了 Host 别名（如 Host github-work），但 Composer/Git 不会自动识别别名写法，除非 URL 显式使用该别名。
- 若
composer.json写的是git@github.com:...，而你的~/.ssh/config只对Host github-work生效，则不会命中配置 - 检查
~/.ssh/config是否包含类似Host github.com的精确匹配段，并确认其中IdentityFile指向正确的私钥 - 避免在
config中使用通配符（如Host *）覆盖关键设置；可用ssh -F ~/.ssh/config -vT git@github.com查看实际加载的配置和认证过程
ssh -T 和 git clone 复现，比直接跑 composer install 更快定位。 
