Sæt SSM Agents proxy på dens faktiske systemd-tjeneste
Brug agentens drop-in og metadata-omgåelse, og skeln derefter dens forbindelse fra en Image Builder-komponents egen curl-anmodning.
Identificer først afsenderen, der fejler: SSM Agent-kommunikation eller en download inde i Image Builder-komponenten. En SSH-shell-eksport opdaterer ikke den kørende agent.
For den almindelige amazon-ssm-agent systemd-enhed skal du flette den dokumenterede drop-in i /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"HTTP-endepunktet kan bære HTTPS-destinationer. Når agenten må bruge en offentlig mellemled for sine offentlige AWS-tjenesteslutpunkter, leverer HTTP-proxy-listen kandidater til disse URL'er; bevar metadata-omgåelsen. Hold 169.254.169.254 direkte til instansmetadata; AWS dokumenterer også [fd00:ec2::254] til IPv6-metadataendepunktet.
Genindlæs systemd, og genstart den faktiske agentenhed efter ændringen. Ubuntu snap-pakning bruger en anden enhed/drop-in-placering, så tilpas efter installationen.
Hvis agenten virker, men komponentens curl fejler, skal du levere den kommandos miljø. Små bogstaver http_proxy betyder noget for curl; en vellykket agenttransaktion fastslår ikke disse underanmodningsinput.