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 更快定位。










