破解私有源码拉取阻碍：配置Composer注入SSH密钥实现无感鉴权

破解私有源码拉取阻碍：配置Composer注入SSH密钥实现无感鉴权

先说一个核心事实：Composer本身并不处理SSH密钥，它只是忠实地调用git clone命令。所以，我们常说的“为Composer注入密钥”，本质上，是确保Git在执行克隆操作时，能够静默地读取并使用你的私钥。只要git clone git@github.com:org/repo.git这条命令能顺畅执行，Composer就绝不会卡住。

为什么 composer install 卡在 Cloning into '/tmp/xxx'？

这其实是个“背锅”现象。报错的不是Composer，而是Git在SSH认证失败后，转而尝试请求密码输入。而Composer并不接管标准输入（stdin），于是整个进程就挂在那里，看似“卡住”了。典型的症状包括：

• 终端光标静止不动，没有任何后续输出或错误提示。
• 日志里最后一行是Cloning into '/tmp/xxx'，然后戛然而止。
• 在CI/CD环境中，任务最终因超时退出，错误日志里可能只有一句孤零零的Permission denied (publickey)。

归根结底，问题只有一个：本地的Git无法通过SSH方式，无交互地连接到目标代码仓库。

验证 SSH 连通性必须手动做三件事

这一步千万别图省事跳过——绝大多数失败都源于这里的疏漏。请严格按照顺序执行以下检查：

• 执行ssh -T git@github.com（请将github.com替换为你的实际Git服务器域名）。成功的关键标志是看到类似Hi username! You've successfully authenticated的欢迎信息。
• 运行ssh-add -l。如果没有任何输出，说明你的私钥并未加载到ssh-agent中。此时需要执行ssh-add ~/.ssh/id_ed25519（请根据你的私钥实际路径调整）。
• 最后，直接用Git克隆一次：git clone git@github.com:org/private-repo.git。这个操作必须能完整拉取代码，过程中不能出现输入密码的提示，也不能中途中断。

这三步，任何一步失败，Composer都绝无可能成功。另外，一个隐蔽的陷阱是私钥文件权限：必须设置为600，否则ssh-add会静默拒绝加载，而你却很难察觉。

composer.json 里写 SSH 地址的硬性规则

即便SSH通道已经畅通，composer.json里一个字符的差错，也可能导致整个仓库配置被Composer忽略。务必遵守这些硬性规则：

• "type"字段必须且只能是"vcs"。写成"git"、"package"或者留空，都会导致配置失效。
• "url"必须使用完整的SSH格式："git@github.com:org/private-repo.git"。注意是冒号分隔，并且以.git结尾。
• require部分声明的包名（例如"org/private-repo"），必须与私有仓库根目录下composer.json文件中"name"字段的值逐字符完全一致（大小写敏感）。
• 版本号不能简单地写"*"或省略，必须明确指定一个可解析的引用，如"dev-main"、"1.0.0"等。

如果使用的是自定义域名（例如git.internal），那么~/.ssh/config文件中的Host条目必须与URL中的主机名完全一致，并且需要包含User git和IdentityFile（指定私钥路径）的配置。

CI 环境下别硬扛 SSH，优先换 HTTPS + token

在GitHub Actions、GitLab CI等自动化环境中，默认没有交互式的ssh-agent，ssh-add命令很容易因为换行符问题（Windows环境下的\r\n）或权限问题而静默失败。更稳健的策略是绕开SSH，采用HTTPS方案：

• 生成一个只读的Personal Access Token（GitHub）或Project Access Token（GitLab），并赋予其read_package_registry类权限。
• 在composer.json中直接改用HTTPS格式的URL："https://token:x-oauth-basic@github.com/org/private-repo.git"。
• 或者，通过COMPOSER_AUTH环境变量注入认证信息，格式为JSON：{"github-oauth": {"github.com": "${GITHUB_TOKEN}"}}。

这样做，彻底规避了SSH配置的所有复杂性，也避免了因~/.ssh/config全局配置或密钥格式兼容性带来的潜在问题。

最后，提一个最常被忽略的细节：PHP进程的运行用户（例如www-data）和你当前登录的终端用户，很可能不是同一个。这意味着，即使你在自己的账户下完美配置了SSH，PHP进程的~/.ssh目录也可能是空的，且没有启动ssh-agent——这时，通过Web发起的Composer请求依然会失败。这一点在部署到生产服务器时尤其需要警惕。