AWS CDK中DockerImageAsset的buildSsh套接字偶发失效排查求助

使用AWS CDK部署栈时，通过DockerImageAsset的buildSsh属性传入SSH套接字，以访问GitHub私有仓库构建镜像。该配置多数时候正常，但会出现持续一段时间的失效，失效期间无明显配置差异，而本地命令行直接传递SSH凭证构建始终正常。

现有细节 #

代码实现 #

CDK栈中传递SSH套接字的代码：

// lib/cdk-stack.js

import * as cdk from 'aws-cdk-lib';
import * as ecrAssets from 'aws-cdk-lib/aws-ecr-assets';
import * as ecrDeploy from 'cdk-ecr-deployment';

// ...

export class CdkJsStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // ...

    const asset = new ecrAssets.DockerImageAsset(this, id + '-DockerImage', {
      directory: path.join(__dirname, '..'),
      networkMode: ecrAssets.NetworkMode.HOST,
      buildSsh: process.env.SSH_AUTH_SOCK, // pass the SSH agent socket here
      invalidation: {
        buildArgs: false,
      },
    });

    new ecrDeploy.ECRDeployment(this, id + '-DeployDockerImage', {
      src: new ecrDeploy.DockerImageName(asset.imageUri),
      dest: new ecrDeploy.DockerImageName(repository.repositoryUri),
    });

    // ...
}

Dockerfile相关代码：

COPY ./requirements.txt /app
RUN mkdir -p -m 0600 ~/.ssh && ssh-keyscan github.com >> ~/.ssh/known_hosts
RUN --mount=type=ssh pip install -r requirements.txt  

错误信息 #

#9 [stage-0 5/9] RUN --mount=type=ssh pip install -r requirements.txt
#9 1.498 Collecting data_interface@ git+ssh://git@github.com/.../data_interface.py.git@... (from -r requirements.txt (line 4))
#9 1.498   Cloning ssh://****@github.com/.../data_interface.py.git (to revision ...) to /tmp/pip-install-jf3sh2f8/data-interface_...
#9 1.500   Running command git clone --filter=blob:none --quiet 'ssh://****@github.com/.../data_interface.py.git' /tmp/pip-install-jf3sh2f8/data-interface_...
#9 2.215   git@github.com: Permission denied (publickey).
#9 2.215   fatal: Could not read from remote repository.
#9 2.216 
#9 2.216   Please make sure you have the correct access rights
#9 2.217   and the repository exists.
#9 2.225   error: subprocess-exited-with-error
#9 2.225   
#9 2.225   × git clone --filter=blob:none --quiet 'ssh://****@github.com/.../data_interface.py.git' /tmp/pip-install-jf3sh2f8/data-interface_... did not run successfully.
#9 2.225   │ exit code: 128
#9 2.225   ╰─> See above for output.
#9 2.225   
#9 2.225   note: This error originates from a subprocess, and is likely not a problem with pip.
#9 2.226 error: subprocess-exited-with-error
#9 2.226 
#9 2.226 × git clone --filter=blob:none --quiet 'ssh://****@github.com/.../data_interface.py.git' /tmp/pip-install-jf3sh2f8/data-interface_... did not run successfully.
#9 2.226 │ exit code: 128
#9 2.226 ╰─> See above for output.
#9 2.226 
#9 2.226 note: This error originates from a subprocess, and is likely not a problem with pip.
#9 2.464 
#9 2.464 [notice] A new release of pip is available: 23.2.1 -> 23.3.2
#9 2.464 [notice] To update, run: pip install --upgrade pip
#9 ERROR: process "/bin/sh -c pip install -r requirements.txt" did not complete successfully: exit code: 1

失效表现 #

失效并非随机间歇性出现，通常会持续一段时间后自行恢复。

排查方向 #

1. SSH代理状态一致性检查 #

• 失效时，确认本地SSH_AUTH_SOCK指向的代理进程是否仍在运行：执行ps aux | grep ssh-agent，对比正常与失效时的进程状态
• 检查代理中的密钥是否有效：失效时执行ssh-add -l，确认目标GitHub仓库对应的公钥是否在列表中；正常时也执行该命令做对比
• 验证代理连通性：失效时手动执行ssh -T git@github.com，看是否能正常认证，和CDK构建时的环境做对比

2. CDK构建环境的上下文差异 #

• 确认CDK执行时的环境变量是否完整：失效时在CDK代码中添加临时打印逻辑，输出process.env.SSH_AUTH_SOCK，对比正常时的套接字路径是否一致
• 检查CDK是否使用了缓存的构建上下文：由于设置了invalidation.buildArgs: false，确认CDK是否复用了之前的构建缓存，导致SSH套接字路径失效（比如代理重启后套接字路径变化，但缓存未更新）
• 查看CDK的构建日志：启用CDK详细日志模式（cdk deploy -v），检查构建过程中SSH套接字的传递是否有异常输出

3. Docker构建的SSH挂载细节 #

• 验证Docker版本：对比正常与失效时的Docker版本，确认是否存在版本兼容性问题（--mount=type=ssh的行为在不同Docker版本中可能有差异）
• 检查Docker守护进程的权限：失效时确认Docker是否有权限访问SSH_AUTH_SOCK对应的套接字文件（查看文件权限ls -l $SSH_AUTH_SOCK，确认Docker进程的用户组是否有访问权限）
• 在Docker构建中添加调试步骤：修改Dockerfile，在RUN --mount=type=ssh前添加RUN echo $SSH_AUTH_SOCK && ssh-add -l && ssh -T git@github.com，输出构建时的SSH状态信息

4. GitHub侧的权限与限制 #

• 检查GitHub SSH密钥的使用频率：查看GitHub账户的SSH密钥日志（GitHub设置→SSH和GPG密钥→查看日志），确认是否出现密钥被临时限制的情况（比如短时间内多次认证触发风控）
• 确认仓库的访问权限：失效时检查目标私有仓库的成员权限，确认当前SSH密钥对应的账户是否仍有读取权限
• 检查GitHub的状态：确认失效时段是否存在SSH服务故障

5. 系统级别的资源限制 #

• 检查本地系统的文件描述符限制：失效时查看系统的文件描述符使用情况（ulimit -n，lsof | grep ssh），确认是否因资源耗尽导致代理套接字无法访问
• 检查防火墙或安全软件：确认失效时段是否有防火墙、杀毒软件拦截了SSH代理与Docker之间的通信

内容的提问来源于stack exchange，提问作者Gabriele