Résolution des problèmes de disponibilité des nœuds gérés - AWS Systems Manager
Solution 1 : vérifier que SSM Agent est installé et s'exécute sur le nœud géréSolution 2 : vérifier qu'un profil d'IAMinstance a été spécifié pour l'instance (EC2instances uniquement)Solution 3 : vérifier la connectivité des points de terminaison de serviceSolution 4 : vérifier la prise en charge du système d'exploitation cibleSolution 5 : vérifier que vous travaillez de la même manière Région AWS que l'EC2instance AmazonSolution 6 : vérifier la configuration du proxy à laquelle vous avez postulé SSM Agent sur votre nœud géréSolution 7 : installer un TLS certificat sur les instances gérées

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de disponibilité des nœuds gérés

Pour plusieurs AWS Systems Manager fonctionnalités telles que Run Command, Distributor, et Session Manager, vous pouvez choisir de sélectionner manuellement les nœuds gérés sur lesquels vous souhaitez exécuter une opération. Après avoir spécifié que vous souhaitez choisir les nœuds manuellement, le système affiche alors une liste de nœuds gérés sur lesquels vous pouvez exécuter l'opération.

Cette rubrique fournit des informations qui vous aideront à déterminer pourquoi un nœud géré confirmé comme en cours d'exécution ne figure pas dans vos listes de nœuds gérés dans Systems Manager.

Pour qu'un nœud soit géré par Systems Manager et figure dans les listes de nœuds gérés, il doit remplir trois conditions :

  • SSM Agent doit être installé et exécuté sur le nœud doté d'un système d'exploitation compatible.

    Note

    Certains ont AWS géré Amazon Machine Images (AMIs) sont configurés pour lancer des instances avec SSM Agentpréinstallé. (Vous pouvez également configurer un AMI pour préinstaller SSM Agent.) Pour plus d'informations, consultez Rechercher AMIs avec le SSM Agent préinstallé.

  • Pour les instances Amazon Elastic Compute Cloud (AmazonEC2), vous devez associer un profil d'instance AWS Identity and Access Management (IAM) à l'instance. Ce profil d'instance permet à celles-ci de communiquer avec le service Systems Manager. Si vous n'attribuez pas de profil d'instance à l'instance, vous devez l'enregistrer à l'aide d'une activation hybride, ce qui ne constitue pas le scénario le plus fréquent.

  • SSM Agent doit être en mesure de se connecter à un point de terminaison Systems Manager afin de s'enregistrer auprès du service. Le nœud géré est ensuite disponible pour le service, comme le confirme le signal que celui-ci envoie toutes les cinq minutes afin de vérifier l'état de l'instance.

  • Une fois que le statut d'un nœud géré a été maintenu Connection Lost pendant au moins 30 jours, il est possible que le nœud ne soit plus répertorié dans le Fleet Manager console. Pour le rétablir dans la liste, le problème à l'origine de la perte de connexion doit être résolu.

Après avoir vérifié qu'un nœud géré est en cours d'exécution, vous pouvez utiliser la commande suivante pour vérifier si SSM Agent enregistré avec succès auprès du service Systems Manager. Cette commande ne renvoie pas de résultats tant que l'enregistrement n'a pas réussi.

Linux & macOS
aws ssm describe-instance-associations-status \
    --instance-id instance-id
Windows
aws ssm describe-instance-associations-status ^
    --instance-id instance-id
PowerShell
Get-SSMInstanceAssociationsStatus `
    -InstanceId instance-id

Si l'enregistrement a abouti et que le nœud géré est disponible pour les opérations de Systems Manager, la commande renvoie des résultats semblables aux suivants.

{
    "InstanceAssociationStatusInfos": [
        {
            "AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
            "Name": "AWS-GatherSoftwareInventory",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Pending",
            "DetailedStatus": "Associated"
        },
        {
            "AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
            "Name": "AWS-RunPatchBaseline",
            "DocumentVersion": "1",
            "AssociationVersion": "1",
            "InstanceId": "i-02573cafcfEXAMPLE",
            "Status": "Queued",
            "AssociationName": "SystemAssociationForScanningPatches"
        }
    ]
}

Si l'enregistrement n'est pas terminé ou a échoué, la commande renvoie des résultats semblables aux suivants :

{
    "InstanceAssociationStatusInfos": []
}

Si la commande ne renvoie aucun résultat au bout de 5 minutes environ, utilisez les informations suivantes pour résoudre les problèmes liés à vos nœuds gérés.

Rubriques

Solution 1 : vérifier que SSM Agent est installé et s'exécute sur le nœud géré

Assurez-vous de disposer de la dernière version de SSM Agent est installé et s'exécute sur le nœud géré.

Pour déterminer si SSM Agent est installé et s'exécute sur un nœud géré, voirVérification du statut de l'SSM Agent et démarrage de l'agent.

Pour installer ou réinstaller SSM Agent sur un nœud géré, consultez les rubriques suivantes :

Solution 2 : vérifier qu'un profil d'IAMinstance a été spécifié pour l'instance (EC2instances uniquement)

Pour les instances Amazon Elastic Compute Cloud (AmazonEC2), vérifiez que l'instance est configurée avec un profil d'instance AWS Identity and Access Management (IAM) qui permet à l'instance de communiquer avec le Systems ManagerAPI. Vérifiez également que votre utilisateur dispose d'une politique de IAM confiance lui permettant de communiquer avec le Systems ManagerAPI.

Note

Les serveurs locaux, les périphériques périphériques et les machines virtuelles (VMs) utilisent un rôle de IAM service au lieu d'un profil d'instance. Pour plus d'informations, voir Créer le rôle IAM de service requis pour Systems Manager dans les environnements hybrides et multicloud.

Pour déterminer si un profil d'instance doté des autorisations nécessaires est attaché à une EC2 instance

  1. Ouvrez la EC2 console Amazon à l'adresse https://console.aws.amazon.com/ec2/.

  2. Dans le panneau de navigation, choisissez Instances.

  3. Sélectionnez l'instance pour laquelle rechercher un profil d'instance.

  4. Dans l'onglet Description du volet inférieur, recherchez le IAMrôle et choisissez le nom du rôle.

  5. Sur la page Résumé du rôle pour le profil d'instance, sous l'onglet Autorisations, vérifiez que AmazonSSMManagedInstanceCore est bien répertorié sous Politiques d'autorisations.

    Si vous utilisez plutôt une politique personnalisée, vérifiez qu'elle fournit les mêmes autorisations que AmazonSSMManagedInstanceCore.

    Ouvrir AmazonSSMManagedInstanceCore dans la console

    Pour plus d'informations sur les autres politiques qui peuvent être associées à un profil d'instance pour Systems Manager, voir Configurer les autorisations d'instance requises pour Systems Manager.

Solution 3 : vérifier la connectivité des points de terminaison de service

Vérifiez que l'instance est connectée aux points de terminaison de service Systems Manager. Cette connectivité est fournie en créant et en configurant des VPC points de terminaison pour Systems Manager, ou en autorisant HTTPS (port 443) le trafic sortant vers les points de terminaison du service.

Pour les EC2 instances Amazon, le point de terminaison du service Systems Manager Région AWS est utilisé pour enregistrer l'instance si la configuration de votre cloud privé virtuel (VPC) autorise le trafic sortant. Toutefois, si la VPC configuration dans laquelle l'instance a été lancée n'autorise pas le trafic sortant et que vous ne pouvez pas modifier cette configuration pour autoriser la connectivité aux points de terminaison du service public, vous devez configurer les points de terminaison d'interface pour vous à la place. VPC

Pour plus d'informations, consultez Améliorer la sécurité des EC2 instances en utilisant des VPC points de terminaison pour Systems Manager.

Solution 4 : vérifier la prise en charge du système d'exploitation cible

Vérifiez que l'opération que vous avez choisie peut être exécutée sur le type de nœud géré que vous souhaitez voir figurer dans la liste. Certaines opérations Systems Manager peuvent cibler uniquement des instances Windows ou uniquement des instances Linux. Par exemple, le Systems Manager (SSM) documente AWS-InstallPowerShellModule et ne AWS-ConfigureCloudWatch peut être exécuté que sur des instances Windows. Sur la page Exécuter une commande, si vous sélectionnez l'un de ces documents et que vous sélectionnez Choisir des instances manuellement, seules vos instances Windows sont répertoriées et disponibles à la sélection.

Solution 5 : vérifier que vous travaillez de la même manière Région AWS que l'EC2instance Amazon

Les EC2 instances Amazon sont créées et disponibles dans des régions spécifiques Régions AWS, telles que la région USA Est (Ohio) (us-east-2) ou Europe (Irlande) (eu-west-1). Assurez-vous que vous travaillez dans la Région AWS même EC2 instance Amazon que vous souhaitez utiliser. Pour de plus amples informations, consultez Choisir une région dans Mise en route avec la AWS Management Console.

Solution 6 : vérifier la configuration du proxy à laquelle vous avez postulé SSM Agent sur votre nœud géré

Vérifiez que la configuration du proxy à laquelle vous avez appliqué votre demande SSM Agent sur votre nœud géré est correct. Si la configuration de proxy est incorrecte, le nœud ne peut pas se connecter aux points de terminaison de service requis, ou Systems Manager risque de mal identifier le système d'exploitation du nœud géré. Pour plus d’informations, consultez Configuration SSM Agent pour utiliser un proxy sur des nœuds Linux et Configuration SSM Agent pour utiliser un proxy pour Windows Server Instances.

Solution 7 : installer un TLS certificat sur les instances gérées

Un certificat Transport Layer Security (TLS) doit être installé sur chaque instance gérée que vous utilisez AWS Systems Manager. Services AWS utilisez ces certificats pour chiffrer les appels vers d'autres Services AWS personnes.

Un TLS certificat est déjà installé par défaut sur chaque EC2 instance Amazon créée à partir de n'importe quel Amazon Machine Image (AMI). La plupart des systèmes d'exploitation modernes incluent le TLS certificat requis d'Amazon Trust Services CAs dans leur boutique de confiance.

Pour déterminer si le certificat requis est installé sur votre instance, exécutez la commande suivante en fonction du système d'exploitation de celle-ci. Assurez-vous de remplacer le region partie du URL avec l' Région AWS emplacement de votre instance gérée.

Linux & macOS
curl -L https://ssm.region.amazonaws.com
Windows
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com

La commande doit renvoyer une erreur UnknownOperationException. Si vous recevez plutôt un message TLS d'erreurSSL/, le certificat requis risque de ne pas être installé.

Si vous constatez que les certificats Amazon Trust Services CA requis ne sont pas installés sur vos systèmes d'exploitation de base, sur les instances créées à partir de AMIs qui ne sont pas fournis par Amazon ou sur vos propres serveurs locaux et VMs vous devez installer et autoriser un certificat d'Amazon Trust Services, ou utiliser AWS Certificate Manager (ACM) pour créer et gérer des certificats pour un service intégré pris en charge.

L'un des certificats Transport Layer Security (TLS) suivants doit être installé sur chacune de vos instances gérées.

  • Amazon Root CA 1

  • Starfield Services Root Certificate Authority – G2

  • Starfield Class 2 Certificate Authority

Pour plus d'informations sur l'utilisationACM, consultez le guide de AWS Certificate Manager l'utilisateur.

Si les certificats de votre environnement informatique sont gérés par un objet de stratégie de groupe (GPO), vous devrez peut-être configurer la stratégie de groupe pour inclure l'un de ces certificats.

Pour plus d'informations sur les certificats Amazon Root et Starfield, consultez le billet de blog How to Prepare for AWS's Move to Its Own Certificate Authority.