Coloque el proxy de SSM Agent en su servicio systemd real
Use el drop-in del agente y la omisión de metadatos, y luego distinga su conectividad de la propia solicitud curl de un componente de Image Builder.
Primero identifique el emisor que falla: la comunicación de SSM Agent o una descarga dentro del componente de Image Builder. Una exportación por shell SSH no actualiza el agente en ejecución.
Para la unidad systemd normal amazon-ssm-agent, combine el drop-in documentado en /etc/systemd/system/amazon-ssm-agent.service.d/override.conf:
[Service]
Environment="http_proxy=http://proxy.example:8080"
Environment="https_proxy=http://proxy.example:8080"
Environment="no_proxy=169.254.169.254"El punto de conexión HTTP puede transportar destinos HTTPS. Cuando el agente puede usar un intermediario público para sus puntos de conexión públicos de AWS, la lista de proxies HTTP ofrece candidatos para estas URL; conserve la omisión de metadatos. Mantenga 169.254.169.254 directo para los metadatos de la instancia; AWS también documenta [fd00:ec2::254] para el punto de conexión de metadatos IPv6.
Recargue systemd y reinicie la unidad real del agente después del cambio. El empaquetado snap de Ubuntu usa otra ubicación de unidad/drop-in, así que ajústese a la instalación.
Si el agente funciona pero el curl del componente falla, proporcione el entorno de ese comando. Las minúsculas http_proxy importan para curl; una transacción correcta del agente no establece esas entradas de la solicitud hija.