AWS Systems ManagerChange Managersteht neuen Kunden nicht mehr offen. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Änderung der AWS Systems ManagerChange Manager Verfügbarkeit.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Technische Details über die SSM Agent erfahren

Verwenden Sie die Informationen in diesem Thema, um Ihnen bei der Implementierung von AWS Systems Manager Agent (SSM Agent) zu helfen und zu verstehen, wie der Agent funktioniert.

Verhalten der Anmeldeinformationen von SSM Agent-Version 3.2.x.x

SSM Agent speichert einen Satz temporärer Anmeldeinformationen unter /var/lib/amazon/ssm/credentials (für Linux und macOS) oder %PROGRAMFILES%\Amazon\SSM\credentials (für Windows Server), wenn eine Instance mit der Standardkonfiguration für die Host-Verwaltung in Quick Setup eingebunden wird. Die temporären Anmeldeinformationen haben dieselben Berechtigungen wie die IAM-Rolle, die Sie für die Standardkonfiguration für die Host-Verwaltung ausgewählt haben. Auf Linux kann nur das Root-Konto auf diese Anmeldeinformationen zugreifen. Auf Windows Server, können nur das SYSTEM-Konto und lokale Administratoren auf diese Anmeldeinformationen zugreifen.

Priorität der SSM Agent-Anmeldeinformationen

In diesem Thema werden wichtige Informationen darüber beschrieben, wie SSM Agentdie Berechtigung zum Ausführen von Aktionen auf Ihren Ressourcen erhält.

Wenn SSM Agent ın einer Maschine installiert ist, sind Berechtigungen für die Kommunikation mit dem Systems-Manager-Service erforderlich. Auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances werden diese Berechtigungen in einem Instance-Profil bereitgestellt, das an die Instance angehängt ist. Ruft auf einem EC2 Computer SSM Agent normalerweise die erforderlichen Berechtigungen aus der Datei mit gemeinsam genutzten Anmeldeinformationen ab, die sich unter /root/.aws/credentials (Linux undmacOS) oder %USERPROFILE%\.aws\credentials (Windows Server) befindet. Die erforderlichen Berechtigungen werden dieser Datei während des Hybrid-Aktivierungsvorgangs hinzugefügt. Wenn ein hybrider aktivierter Knoten abgemeldet wird, kann der Agent in den Ruhezustand wechseln. Weitere Informationen finden Sie unter Grundlegendes zum SSM Agent-Ruhezustand.

In seltenen Fällen kann es jedoch sein, dass eine Maschine Berechtigungen zu mehr als einem der Speicherorte enthält, in denen SSM Agent prüft, ob Berechtigungen zum Ausführen der Aufgaben vorhanden sind.

Angenommen, Sie haben eine EC2 Instanz so konfiguriert, dass sie von Systems Manager verwaltet wird. Diese Konfiguration umfasst das Anhängen eines Instance-Profils. Aber dann entscheiden Sie sich, diese Instance auch für Entwickler- oder Endbenutzer-Aufgaben zu verwenden und installieren die AWS Command Line Interface (AWS CLI) darauf. Diese Installation führt dazu, dass zusätzliche Berechtigungen zu einer Anmeldeinformationsdatei auf der Instance hinzugefügt werden.

Wenn Sie einen Systems Manager-Befehl für die Instance ausführen,versucht SSM Agent möglicherweise, Anmeldeinformationen zu verwenden, die sich von denen unterscheiden, die von ihm erwartet werden, z. B. aus einer Anmeldeinformationsdatei anstelle eines Instance-Profils. Das liegt daran, dass SSM Agent in der Reihenfolge nach Anmeldeinformationen sucht, die für die Standard-Anbieterkette für Anmeldeinformationen vorgeschrieben ist.

Die Standard-Anbieterkette sucht in folgender Reihenfolge nach Anmeldeinformationen:

Verwandte Informationen finden Sie in den folgenden Themen:

Konfigurieren von SSM Agent für die Verwendung mit dem Federal Information Processing Standard (FIPS)

Wenn Sie Systems Manager mit nach dem Federal Information Processing Standard (FIPS) 140-3 validierten kryptografischen Modulen verwenden müssen, können Sie AWS Systems Manager Agent (SSM Agent) so konfigurieren, dass die FIPS-Endpunkte in unterstützten Regionen verwendet werden.

Jedes Mal, wenn Sie die Konfiguration ändern, starten Sie SSM Agent neu.

Sie können andere Features von SSM Agent mit dem gleichen Verfahren personalisieren. Eine up-to-date Liste der verfügbaren Konfigurationseigenschaften und ihrer Standardwerte finden Sie unter Definitionen von Konfigurationseigenschaften im amazon-ssm-agent Repository unter GitHub.

Weitere Informationen zur AWS Unterstützung von FIPS finden Sie unter Federal Information Processing Standard (FIPS) 140-3.

Über das lokale ssm-user-Konto

Ab Version 2.3.50.0 von SSM Agent, erstellt der Agent ein lokales Benutzerkonto namens ssm-user und fügt es dem /etc/sudoers.d-Verzeichnis (Linux und macOS) bzw. der Administratorengruppe (Windows Server) hinzu. Auf Agenten-Versionen vor 2.3.612.0 wird das Konto beim ersten Start bzw. Neustart des SSM Agent nach der Installation erstellt. Auf Version 2.3.612.0 und höher wird das ssm-user-Konto beim ersten Start einer Sitzung auf einer Instance erstellt. Dieser ssm-user ist der standardmäßige OS-Benutzer, wenn eine Sitzung in Session Manager, einem Tool in AWS Systems Manager, startet. Sie können die Berechtigungen ändern, indem Sie ssm-user einer Gruppe mit weniger Berechtigungen hinzufügen oder die sudoers-Datei entsprechend ändern. Das ssm-user-Konto wird bei einer Deinstallation von SSM Agent nicht aus dem System entfernt.

Unter Windows Server legt der SSM Agent beim Start einer jeden Sitzung ein neues Passwort für das ssm-user-Konto fest. Auf Linux-verwalteten Instances werden keine Passwörter für ssm-user festgelegt.

Ab SSM Agent Version 2.3.612.0 wird das ssm-user-Konto nicht automatisch auf Windows Server-Maschinen erstellt, die als Domain-Controller verwendet werden. Um Session Manager auf einem Windows Server-Domain-Controller zu verwenden, erstellen Sie das ssm-user-Konto manuell, sofern es noch nicht vorhanden ist, und weisen dem Benutzer Domain-Administratorberechtigungen zu.

SSM Agent und die Instance Metadata Service (IMDS)

Systems Manager ist auf EC2 Instanzmetadaten angewiesen, um korrekt zu funktionieren. Systems Manager kann entweder über Version 1 oder Version 2 desInstance Metadata Service (IMDSv1 und IMDSv2) auf Instance-Metadaten zugreifen. Ihre Instanz muss auf die IPv4 Adresse des Instanz-Metadatendienstes zugreifen können: 169.254.169.254. Weitere Informationen finden Sie unter Instance-Metadaten und Benutzerdaten im EC2 Amazon-Benutzerhandbuch.

Behalten SSM Agent up-to-date

Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter Automatisieren von Updates für SSM Agent. Abonnieren Sie die SSM Agent-Versionshinweise-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.

Sicherstellen, dass das SSM Agent-Installationsverzeichnis nicht geändert, verschoben oder gelöscht wird

SSM Agent ist unter /var/lib/amazon/ssm/ (Linux und macOS) und %PROGRAMFILES%\Amazon\SSM\ (Windows Server) installiert. Diese Installationsverzeichnisse enthalten wichtige Dateien und Ordner, die von SSM Agent verwendet werden, wie z. B. eine Anmeldeinformationsdatei, Ressourcen für die prozessübergreifende Kommunikation (IPC) und Orchestrierungsordner. Nichts im Installationsverzeichnis sollte geändert, verschoben oder gelöscht werden. Andernfalls funktioniert SSM Agent möglicherweise nicht mehr richtig.

SSM Agentfortlaufende Updates von AWS-Regionen

Nachdem ein SSM Agent Update in seinem GitHub Repository verfügbar gemacht wurde, kann es bis zu zwei Wochen dauern, bis die aktualisierte Version zu unterschiedlichen AWS-Regionen Zeiten für alle verfügbar ist. Aus diesem Grund erhalten Sie möglicherweise die Fehlermeldung „Auf der aktuellen Plattform nicht unterstützt“ oder „Aktualisierung amazon-ssm-agent auf eine ältere Version, bitte aktivieren Sie die Option Downgrade zulassen, um fortzufahren“, wenn Sie versuchen, eine neue Version von SSM Agent in einer Region bereitzustellen.

Um die für Sie verfügbare Version von SSM Agent zu ermitteln, können Sie einen curl-Befehl ausführen.

Um die im globalen Download-Bucket verfügbare Version des Agenten anzuzeigen, führen Sie den folgenden Befehl aus.

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

Um die Version des Agenten anzuzeigen, die in einer bestimmten Region verfügbar ist, führen Sie den folgenden Befehl aus und ersetzen Sie ihn durch region die Region, in der Sie arbeiten, z. B. us-east-2 für die Region USA Ost (Ohio).

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

Sie können die VERSION-Datei auch direkt in Ihrem Browser ohne einen curl-Befehl öffnen.

SSM Agent-Kommunikationen mit AWS -verwalteten S3-Buckets

Bei der Ausführung verschiedener Systems Manager Manager-Operationen greift AWS Systems Manager Agent (SSM Agent) auf eine Reihe von Amazon Simple Storage Service (Amazon S3) -Buckets zu. Diese S3-Buckets sind öffentlich zugänglich und SSM Agent verbindet sich standardmäßig über HTTP-Aufrufe mit ihnen.

Wenn Sie jedoch einen Virtual Private Cloud (VPC) -Endpunkt in Ihren Systems Manager-Vorgängen verwenden, müssen Sie in einem Amazon Elastic Compute Cloud (Amazon EC2) -Instanzprofil für Systems Manager oder in einer Servicerolle für EC2 Nicht-Maschinen in einer Hybrid- und Multi-Cloud-Umgebung eine ausdrückliche Genehmigung erteilen. Andernfalls haben Ihre Ressourcen keinen Zugriff auf diese öffentlichen Buckets.

Um Ihren verwalteten Knoten Zugriff auf diese Buckets zu gewähren, wenn Sie einen VPC-Endpunkt verwenden, erstellen Sie eine benutzerdefinierte Amazon S3 S3-Berechtigungsrichtlinie und fügen sie dann Ihrem Instance-Profil (für EC2 Instances) oder Ihrer Servicerolle (für nicht EC2 verwaltete Knoten) hinzu.

Informationen zur Verwendung eines VPC-Endpunkts (Virtual Private Cloud) in Ihren Systems Manager-Vorgängen finden Sie unter Verbessern der Sicherheit von EC2 Instanzen mithilfe von VPC-Endpunkten für Systems Manager.

Weitere Informationen finden Sie unter den folgenden Themen:

Erforderliche Bucket-Berechtigungen

In der folgenden Tabelle werden die einzelnen S3-Buckets beschrieben, auf die SSM Agent möglicherweise für Systems Manager-Operationen zugreifen muss.

Von SSM Agent erforderte Amazon S3-Berechtigungen

Beispiel

Das folgende Beispiel veranschaulicht, wie Zugriff auf die S3-Buckets erteilt wird, die in der Region USA Ost (Ohio) (us-east-2) für Systems Manager-Operationen benötigt werden. In den meisten Fällen müssen Sie diese Berechtigungen explizit in einem Instance-Profil oder einer Servicerolle nur dann bereitstellen, wenn Sie einen VPC Endpunkt verwenden.

JSON

{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:GetObject",
                "Resource": [
                    "arn:aws:s3:::aws-windows-downloads-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-us-east-2/*",
                    "arn:aws:s3:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-patch-manager-us-east-2-552881074/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2-552881074/*"
                ]
            }
        ]
    }

Validierung von hybrid-aktivierten Maschinen mit einem Hardware-Fingerabdruck

SSM AgentErfasst bei EC2 Nichtcomputern in einer Hybrid- und Multi-Cloud-Umgebung eine Reihe von Systemattributen (wird als Hardware-Hash bezeichnet) und verwendet diese Attribute, um einen Fingerabdruck zu berechnen. Der Fingerabdruck ist eine undurchsichtige Zeichenfolge, die der Agent an einen bestimmten Systems Manager APIs weitergibt. Dieser eindeutige Fingerabdruck ordnet den Abrufer einem bestimmten hybrid-aktivierten verwalteten Knoten zu. Der Agent speichert den Fingerabdruck und den Hardware-Hash auf der lokalen Festplatte an einem Speicherort namens Vault.

Der Agent berechnet den Hardware-Hash und den Fingerabdruck, wenn die Maschine für die Verwendung mit Systems Manager registriert wird. Anschließend wird der Fingerabdruck an den Systems Manager-Service zurückgegeben, wenn der Agent einen RegisterManagedInstance-Befehl sendet.

Später, wenn ein RequestManagedInstanceRoleToken-Befehl gesendet wird, überprüft der Agent den Fingerabdruck und den Hardware-Hash im Vault, um sicherzustellen, dass die aktuellen Computerattribute mit dem gespeicherten Hardware-Hash übereinstimmen. Wenn die aktuellen Computerattribute mit dem im Vault gespeicherten Hardware-Hash übereinstimmen, übergibt der Agent den Fingerabdruck aus dem Vault an RegisterManagedInstance, was zu einem erfolgreichen Aufruf führt.

Wenn die aktuellen Computerattribute nicht mit dem gespeicherten Hardware-Hash übereinstimmen, berechnet SSM Agent einen neuen Fingerabdruck, speichert den neuen Hardware-Hash und Fingerabdruck im Vault und übergibt den neuen Fingerabdruck an RequestManagedInstanceRoleToken. Dadurch schlägt RequestManagedInstanceRoleToken fehl und der Agent kann kein Rollen-Token für die Verbindung mit dem Systems Manager-Service abrufen.

Dieser Fehler ist vorgesehen und wird als Verifizierungsschritt verwendet, um zu verhindern, dass mehrere verwaltete Knoten als derselbe verwaltete Knoten mit dem Systems-Manager-Service kommunizieren.

Beim Vergleich der aktuellen Computerattribute mit dem im Vault gespeicherten Hardware-Hash verwendet der Agent die folgende Logik, um festzustellen, ob die alten und neuen Hashes übereinstimmen:

Der Ähnlichkeitsschwellenwert wird im Vault als Teil des Hardware-Hash gespeichert.

Der Ähnlichkeitsschwellenwert kann festgelegt werden, nachdem eine Instance mit einem Befehl wie dem folgenden registriert wurde.

Auf Linux-Maschinen:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Auf Windows Server Maschinen, die Folgendes verwenden PowerShell:

cd "C:\Program Files\Amazon\SSM\" `
    .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

SSM Agent auf GitHub

Der Quellcode für SSM Agent ist in GitHub verfügbar, damit Sie den Agenten entsprechend Ihren Anforderungen anpassen können. Wir möchten Sie bitten, uns eventuelle Änderungswünsche mitzuteilen. Amazon Web Services bietet jedoch keine Unterstützung für die Ausführung modifizierter Kopien dieser Software.

Grundlegendes zum SSM Agent-Ruhezustand

AWS Systems Manager Der Ruhezustand von Agent (SSM Agent) ist ein Betriebsmodus, der auftritt, wenn der Agent nicht ordnungsgemäß mit dem Systems Manager Manager-Dienst kommunizieren kann. Während des Ruhezustands reduziert der Agent seine Kommunikationshäufigkeit und wechselt in einen Bereitschaftszustand.

Wenn der SSM Agent-Ruhezustand eintritt

Der SSM Agent-Ruhezustand kann in folgenden Szenarien auftreten:

Kommunikationsverhalten im Ruhezustand

Wenn SSM Agent in den Ruhezustand eintritt, ändert sich das Kommunikationsmuster mit dem Systems-Manager-Service:

Während des Ruhezustands nimmt der Agent weiterhin Authentifizierungs- und Verbindungsversuche mit der reduzierten Häufigkeit vor, kann jedoch keine neuen Befehle verarbeiten oder detaillierte Statusinformationen melden, bis der Ruhezustand behoben ist.

Konfigurationsoptionen zur Verhinderung des Ruhezustands in Hybrid-Instances

Die primäre Konfigurationsoption zur Verhinderung des Ruhezustands aufgrund von Änderungen am Hardware-Fingerabdruck ist die Anpassung des Ähnlichkeitsschwellenwerts:

Auf Linux-Maschinen:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Auf Windows Server-Computern mit: PowerShell

cd "C:\Program Files\Amazon\SSM\" `
.\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

Der Ähnlichkeitsschwellenwert bestimmt, wie genau der Agent die aktuellen Maschinenattribute mit dem gespeicherten Hardware-Hash vergleicht:

Protokollierung und Überwachung des Ruhezustands

Wenn SSM Agent in den Ruhezustand eintritt, werden Protokolleinträge erstellt, anhand derer Sie den Ruhezustand identifizieren und beheben können:

Überwachen Sie diese Protokollquellen, um Ereignisse im Ruhezustand frühzeitig zu erkennen und Korrekturmaßnahmen zu ergreifen, um den normalen Agentbetrieb wiederherzustellen.

Erholung aus dem Ruhezustand

Um sich aus dem Ruhezustand zu erholen, beheben Sie die zugrunde liegende Ursache:

Nachdem Sie das zugrundeliegende Problem behoben haben, sollte der Agent den Ruhezustand automatisch beenden und den normalen Betrieb beim nächsten Kommunikationsversuch wieder aufnehmen.