如何诊断并解决Composer的”Could not read from remote repository” SSH错误？ (公钥认证)

ssh密钥问题需分步排查：先验证密钥存在且已加载，再测试SSH连通性，检查git配置与composer.json中仓库URL类型是否匹配，并确认~/.ssh/config中Host配置准确无误。

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 错误真正卡住人的地方，往往不是密钥本身，而是 Git、SSH config、Composer 三者之间某一层的 URL 解析或代理逻辑没对齐。调试时优先用 ssh -T 和 git clone 复现，比直接跑 composer install 更快定位。