Composer拉取私有仓库报“Permission denied (publickey)”的根本原因与解决方案
Composer拉取私有仓库时提示“Permission denied (publickey)”
相信不少开发者都遇到过这个经典场景：执行 composer install 或 composer update 时，进度条卡在 Git 克隆阶段，紧接着就抛出类似 git@github.com: Permission denied (publickey) 的错误。其实，问题的根源往往不在 Composer 本身。本质上，是 Composer 在调用系统 Git 时，Git 没能找到可用的 SSH 私钥，或者对应的 SSH agent 服务压根没有加载所需的密钥。
确认当前 SSH agent 是否运行并已加载私钥
遇到问题先别急着四处修改配置，第一步应该是验证当前环境的状态。一个简单的命令就能告诉你答案：
- 运行
ssh-add -l。如果系统提示Could not open a connection to your authentication agent，那基本可以断定 SSH agent 服务没有启动。 - 如果命令执行后没有任何输出（一片空白），则说明 agent 虽然正在运行，但还没有加载任何密钥。
- 如果能看到类似
2048 SHA256:xxx /Users/you/.ssh/id_rsa (RSA)这样的密钥信息，恭喜你，密钥已加载。不过，还需要确认这个密钥是否正是目标仓库（比如 GitHub 或 GitLab）所认可的那一个，比如对应的部署密钥或个人访问密钥。
如果需要临时加载私钥，执行 ssh-add ~/.ssh/your_private_key（记得将 your_private_key 替换成你实际的私钥文件名）。这里有个细节：如果私钥设置了密码，此时终端会要求你输入。如果想避免每次输入密码，在 macOS 上可以加上 -K 参数，在 Linux 上则可以借助 keychain 等工具实现持久化——当然，在共享或公共环境中，这么做需要格外谨慎。
让 Composer 始终走 SSH agent 而非直读磁盘私钥
Composer 默认完全信任 Git 的行为，而 Git 在克隆时又会默认尝试使用 ssh-agent。问题在于，很多终端会话（尤其是 IDE 内置的终端、CI/CD 环境，或者经过多次跳转的远程 SSH 登录）并不会自动继承 agent 的连接。这里的关键，在于一个名为 SSH_AUTH_SOCK 的环境变量：
- 首先检查它是否被设置：运行
echo $SSH_AUTH_SOCK。正常情况下，应该会输出一个路径，在 macOS 上类似/private/tmp/com.apple.launchd.xxx/Listeners，在 Linux 上则类似/tmp/ssh-xxx/agent.xxxx。 - 如果输出为空，那就意味着当前 shell 并没有连接到 SSH agent。解决方法不是去修改 Composer 的配置，而是重新连接 agent：依次执行
eval $(ssh-agent)和ssh-add ~/.ssh/id_rsa。 - ⚠️ 这里有个常见的误区：不要手动设置
git config core.sshCommand来指向一个带-i参数的 ssh 命令（例如ssh -i ~/.ssh/id_rsa）。这种做法相当于把私钥路径硬编码进了 Git 配置，不仅会丧失 SSH agent 提供的密码管理、多密钥自动路由等便利功能，从安全角度看也并不可取。
CI/CD 或 Docker 环境下 SSH agent 加载失败的典型表现
在 GitHub Actions、GitLab CI 或者本地运行的 docker run 容器里，情况又有些不同。ssh-agent 默认是不运行的，SSH_AUTH_SOCK 这个环境变量也根本不存在。这时候，光执行 ssh-add 是没用的，因为根本没有 agent 可以让你添加密钥。
- 对于 GitHub Actions，推荐使用官方的
webfactory/ssh-agentaction，它会自动启动 agent 并注入所需的环境变量。 - 在 GitLab CI 中，可以在 job 的
before_script阶段处理：先执行eval $(ssh-agent -s)启动 agent，然后通过ssh-add <(echo "$SSH_PRIVATE_KEY")加载密钥（注意，这里的$SSH_PRIVATE_KEY通常是预设的 CI 变量，可能需要先进行 base64 解码或写入临时文件）。 - 在 Docker 容器 内部，除非显式地将宿主机的
SSH_AUTH_SOCK环境变量和对应的 socket 文件挂载进去（这种做法并不推荐），否则更稳妥的方案是放弃 SSH 方式，转而使用 deploy token 或者 HTTPS 协议配合 personal access token（通过composer config http-basic进行配置）。
最后必须强调一个安全原则：私钥永远不应该出现在 composer.json 文件、Git 提交历史或者 Docker 镜像的某一层里。使用 SSH agent 的方式，仅仅传递一个 socket 句柄，是目前在安全性与便利性之间取得最佳平衡的方案。
