

• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). 

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.

# Gestion des nœuds dans les environnements hybrides et multicloud avec Systems Manager
<a name="systems-manager-hybrid-multicloud"></a>

Vous pouvez l'utiliser AWS Systems Manager pour gérer à la fois des instances Amazon Elastic Compute Cloud (EC2) et un certain nombre de types de machines non EC2. Cette section décrit les tâches de configuration effectuées par les administrateurs système et de compte pour gérer des machines non EC2 à l'aide de Systems Manager dans un *environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types)*. Une fois ces étapes terminées, les utilisateurs auxquels l' Compte AWS administrateur a accordé des autorisations peuvent utiliser Systems Manager pour configurer et gérer les machines non EC2 de leur organisation.

Toute machine configurée pour être utilisée avec Systems Manager est un *nœud géré*.

**Note**  
Vous pouvez enregistrer des appareils de périphérie en tant que nœuds gérés en utilisant les mêmes étapes d'activation hybride que celles utilisées pour d'autres machines non EC2. Ces types de périphériques périphériques incluent à la fois les AWS IoT appareils et les appareils autres que AWS IoT les appareils. Utilisez le processus décrit dans cette section pour configurer ces types d'appareils de périphérie.  
Systems Manager prend également en charge les périphériques utilisant le logiciel AWS IoT Greengrass Core. Le processus de configuration et les exigences pour les périphériques AWS IoT Greengrass principaux sont différents de ceux pour AWS IoT les périphériques périphériques autres que les AWS périphériques périphériques. Pour plus d'informations sur l'enregistrement des AWS IoT Greengrass appareils à utiliser avec Systems Manager, consultez[Gestion des appareils de périphérie avec Systems Manager](systems-manager-setting-up-edge-devices.md).
Les machines macOS non EC2 ne sont pas prises en charge pour les environnements hybrides et multicloud Systems Manager.

Si vous prévoyez d'utiliser Systems Manager pour gérer des instances Amazon Elastic Compute Cloud (Amazon EC2), ou d'utiliser des instances Amazon EC2 et des machines non EC2 dans un environnement hybride et multicloud, commencez par suivre les étapes de la section [Gestion des instances EC2 avec Systems Manager](systems-manager-setting-up-ec2.md). 

Après avoir configuré votre environnement hybride et multicloud pour Systems Manager, vous pourrez effectuer les opérations suivantes : 
+ Créer une procédure cohérente et sécurisée pour gérer à distance vos charges de travail hybrides et multicloud depuis un emplacement unique, à l'aide des mêmes outils ou des mêmes scripts.
+ Centralisez le contrôle d'accès pour les actions qui peuvent être effectuées sur vos machines à l'aide de Gestion des identités et des accès AWS (IAM).
+ Centralisez l'audit des opérations effectuées sur vos machines en consultant l'activité de l'API enregistrée dans AWS CloudTrail.

  Pour plus d'informations sur l'utilisation CloudTrail pour surveiller les actions de Systems Manager, consultez[Journalisation des appels d' AWS Systems Manager API avec AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ Centralisez la surveillance en configurant Amazon EventBridge et Amazon Simple Notification Service (Amazon SNS) pour envoyer des notifications concernant le succès de l'exécution du service.

  Pour plus d'informations sur l'utilisation EventBridge pour surveiller les événements de Systems Manager, consultez[Surveillance des événements de Systems Manager avec Amazon EventBridge](monitoring-eventbridge-events.md).

**À propos des nœuds gérés**  
*Une fois que vous avez terminé de configurer vos machines non-EC2 pour Systems Manager comme décrit dans cette section, vos machines activées par des hybrides sont répertoriées AWS Management Console et décrites comme des nœuds gérés.* Dans la console, néanmoins, les ID de vos nœuds gérés activés par un système hybride se distinguent des instances Amazon EC2 par le préfixe « mi- ». Les instances Amazon EC2 IDs utilisent le préfixe « i- ».

Un nœud géré est une machine configurée pour Systems Manager. Auparavant, les nœuds gérés étaient tous appelés instances gérées. Le terme *instance* fait désormais référence uniquement aux instances EC2. La [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html)commande a été nommée avant ce changement de terminologie.

Pour de plus amples informations, veuillez consulter [Utilisation des nœuds gérés](fleet-manager-managed-nodes.md).

**Important**  
Nous vous recommandons vivement d'éviter d'utiliser des versions de système d'exploitation ayant atteint End-of-Life (EOL). Les fournisseurs de systèmes d'exploitation, y compris, ne fournissent AWS généralement pas de correctifs de sécurité ou d'autres mises à jour pour les versions qui ont atteint la fin de vie. Le fait de continuer à utiliser un système EOL augmente considérablement le risque de ne pas pouvoir appliquer les mises à niveau, y compris les correctifs de sécurité, et d'autres problèmes opérationnels. AWS ne teste pas les fonctionnalités de Systems Manager sur les versions du système d'exploitation ayant atteint la fin de vie.

**À propos des niveaux d'instances**  
Systems Manager offre un niveau d'instances standard et un niveau d'instances avancées pour les nœuds gérés non EC2 de votre environnement hybride et multicloud. Le niveau d'instances standard vous permet d'enregistrer un maximum de 1 000 machines activées par un système hybride par Compte AWS et par Région AWS. Si vous avez besoin d'enregistrer plus de 1 000 machines non EC2 dans un seul compte et une seule région, utilisez le niveau d'instances avancées. Les instances avancées vous permettent également de vous connecter à vos machines non-EC2 en utilisant. AWS Systems Manager Session Manager Session Managerfournit un accès shell interactif à vos nœuds gérés.

Pour de plus amples informations, veuillez consulter [Configuration des niveaux d'instance](fleet-manager-configure-instance-tiers.md).

**Topics**
+ [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](hybrid-multicloud-service-role.md)
+ [Créer une activation hybride pour enregistrer des nœuds avec Systems Manager](hybrid-activation-managed-nodes.md)
+ [Installer SSM Agent sur les nœuds Linux hybrides](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Installer SSM Agent sur les nœuds hybrides Windows Server](hybrid-multicloud-ssm-agent-install-windows.md)

# Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud
<a name="hybrid-multicloud-service-role"></a>

Les machines non EC2 (Amazon Elastic Compute Cloud) dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) nécessitent un rôle de service Gestion des identités et des accès AWS (IAM) pour communiquer avec le service. AWS Systems Manager Le rôle octroie à AWS Security Token Service (AWS STS) l'approbation [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) au service Systems Manager. Vous devez uniquement créer une fonction du service pour un environnement hybride et multicloud une fois pour chaque Compte AWS. Toutefois, vous pouvez choisir de créer plusieurs fonctions du service pour différentes activations hybrides si les machines de votre environnement hybride et multicloud requièrent des autorisations différentes.

Les procédures suivantes expliquent comment créer la fonction de service requise à l'aide de la console Systems Manager ou de votre outil de ligne de commande préféré.

## Utilisation du AWS Management Console pour créer un rôle de service IAM pour les activations hybrides de Systems Manager
<a name="create-service-role-hybrid-activation-console"></a>

Utilisez la procédure suivante pour créer une fonction de service pour une activation hybride. Cette procédure utilise la politique `AmazonSSMManagedInstanceCore` pour la fonctionnalité principale de Systems Manager. Selon votre cas d’utilisation, vous devrez peut-être ajouter des politiques supplémentaires à votre fonction de service pour que vos machines sur site puissent accéder à d’autres outils Systems Manager ou Services AWS. Par exemple, sans accès aux compartiments AWS gérés Amazon Simple Storage Service (Amazon S3) requisPatch Manager, les opérations de correction échouent.

**Pour créer un rôle de service (console)**

1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Dans le volet de navigation, sélectionnez **Rôles**, puis **Créer un rôle**.

1. Pour **Select trusted entity** (Sélectionner une entité de confiance), effectuez les choix suivants :

   1. Pour **Trusted entity** (Entité de confiance), choisissez **Service AWS**.

   1. Pour les **autres cas d'utilisation Services AWS**, choisissez **Systems Manager**.

   1. Sélectionnez **Systems Manager**.

      L’image suivante met en évidence l’emplacement de l’option Systems Manager.  
![\[Systems Manager est l’une des options du cas d’utilisation.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/iam_use_cases_for_MWs.png)

1. Choisissez **Suivant**. 

1. Sur la page **Add permissions** (Ajouter des autorisations), procédez comme suit : 
   + Utilisez le champ **de recherche** pour trouver la SSMManaged InstanceCore politique **d'Amazon**. Cochez la case correspondant à son nom, comme indiqué dans l’illustration suivante.   
![\[La case à cocher est sélectionnée dans la SSMManaged InstanceCore ligne Amazon.\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/setup-instance-profile-2.png)
**Note**  
La console conserve votre sélection même si vous recherchez d'autres politiques.
   + Si vous avez créé une politique de compartiment S3 personnalisée au cours de la procédure [(Facultatif) créer une politique personnalisée pour l'accès au compartiment S3](setup-instance-permissions.md#instance-profile-custom-s3-policy), recherchez-la et cochez la case en regard de son nom.
   + Si vous envisagez de joindre des machines non EC2 à un Active Directory géré par Directory Service, recherchez **Amazon SSMDirectory ServiceAccess** et cochez la case à côté de son nom.
   + Si vous prévoyez d'utiliser EventBridge ou CloudWatch Logs pour gérer ou surveiller votre nœud géré, recherchez **CloudWatchAgentServerPolicy**et cochez la case à côté de son nom.

1. Choisissez **Suivant**.

1. Pour **Nom de rôle**, saisissez un nom pour votre nouveau rôle de serveur IAM, par exemple, **SSMServerRole**.
**Note**  
Notez le nom de rôle. Vous pouvez choisir ce rôle lorsque vous enregistrez de nouvelles machines à gérer à l'aide de Systems Manager.

1. (Facultatif) Pour **Description**, mettez à jour la description pour ce rôle de serveur IAM.

1. (Facultatif) Pour **Tags** (Balises), ajoutez une ou plusieurs paires clé-valeur de balise afin d'organiser, de suivre ou de contrôler l'accès pour ce rôle. 

1. Sélectionnez **Créer un rôle**. Le système vous renvoie à la page **Rôles**.

## Utilisation du AWS CLI pour créer un rôle de service IAM pour les activations hybrides de Systems Manager
<a name="create-service-role-hybrid-activation-cli"></a>

Utilisez la procédure suivante pour créer une fonction de service pour une activation hybride. Cette procédure utilise la politique `AmazonSSMManagedInstanceCore` pour la fonctionnalité principale de Systems Manager. Selon votre cas d’utilisation, vous devrez peut-être ajouter des politiques supplémentaires à votre fonction du service pour vos machines non EC2 dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types) afin de pouvoir accéder à d’autres outils ou Services AWS.

**Exigence pour les politiques de compartiment S3**  
Dans les cas suivants, vous devez créer une politique d'autorisation IAM personnalisée pour les compartiments Amazon Simple Storage Service (Amazon S3) avant de terminer cette procédure :
+ **Cas 1** — Vous utilisez un point de terminaison VPC pour connecter en privé votre VPC aux services de point de terminaison VPC pris en charge et Services AWS alimentés par. AWS PrivateLink
+ **Cas 2** – Vous prévoyez d'utiliser un compartiment Amazon S3 que vous créez dans le cadre de vos opérations Systems Manager, par exemple pour stocker la sortie des commandes Run Command ou des sessions Session Manager dans un compartiment S3. Avant de continuer, suivez les étapes de [Créer une politique de compartiment S3 personnalisée pour un profil d'instance](setup-instance-permissions.md#instance-profile-custom-s3-policy). Les informations sur les politiques de compartiment S3 de cette rubrique s'appliquent également à votre rôle de service.

------
#### [ AWS CLI ]

**Pour créer une fonction du service IAM pour un environnement hybride et multicloud (AWS CLI)**

1. Installez et configurez le AWS Command Line Interface (AWS CLI), si ce n'est pas déjà fait.

   Pour de plus amples informations, consultez [Installation ou mise à jour de la version la plus récente de l' AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

1. Sur votre machine locale, créez un fichier texte avec un nom tel que `SSMService-Trust.json` avec la politique d'approbation suivante. Assurez-vous d'enregistrer le fichier avec l'extension de fichier `.json`. Assurez-vous de spécifier votre Compte AWS et le Région AWS dans l'ARN dans lequel vous avez créé votre activation hybride. Remplacez le numéro *placeholder values* de compte et la région par vos propres informations.

------
#### [ JSON ]

****  

   ```
   {
      "Version":"2012-10-17",		 	 	 
      "Statement":[
         {
            "Sid":"",
            "Effect":"Allow",
            "Principal":{
               "Service":"ssm.amazonaws.com"
            },
            "Action":"sts:AssumeRole",
            "Condition":{
               "StringEquals":{
                  "aws:SourceAccount":"123456789012"
               },
               "ArnEquals":{
                  "aws:SourceArn":"arn:aws:ssm:us-east-1:111122223333:*"
               }
            }
         }
      ]
   }
   ```

------

1. Ouvrez le AWS CLI, et dans le répertoire où vous avez créé le fichier JSON, exécutez la commande [create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) pour créer le rôle de service. Cet exemple crée un rôle nommé `SSMServiceRole`. Vous pouvez choisir un autre nom si vous préférez.

------
#### [ Linux & macOS ]

   ```
   aws iam create-role \
       --role-name SSMServiceRole \
       --assume-role-policy-document file://SSMService-Trust.json
   ```

------
#### [ Windows ]

   ```
   aws iam create-role ^
       --role-name SSMServiceRole ^
       --assume-role-policy-document file://SSMService-Trust.json
   ```

------

1. Exécutez la [attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)commande comme suit pour autoriser le rôle de service que vous venez de créer à créer un jeton de session. Ce jeton de session autorise votre nœud géré à exécuter des commandes à l'aide de Systems Manager.
**Note**  
Les politiques que vous ajoutez pour un profil de service pour des nœuds gérés dans un environnement hybride et multicloud sont les mêmes politiques que celles utilisées pour créer un profil d'instance pour des instances Amazon Elastic Compute Cloud (Amazon EC2). Pour de plus amples informations sur les politiques AWS utilisées dans les commandes suivantes, consultez [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md).

   (Obligatoire) Exécutez la commande suivante pour autoriser un nœud géré à utiliser les fonctionnalités AWS Systems Manager de base du service.

------
#### [ Linux & macOS ]

   ```
   aws iam attach-role-policy \
       --role-name SSMServiceRole \
       --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
   ```

------
#### [ Windows ]

   ```
   aws iam attach-role-policy ^
       --role-name SSMServiceRole ^
       --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
   ```

------

   Si vous avez créé une politique de compartiment S3 personnalisée pour votre rôle de service, exécutez la commande suivante pour autoriser AWS Systems Manager Agent (SSM Agent) à accéder aux compartiments que vous avez spécifiés dans la politique. Remplacez *account-id* et *amzn-s3-demo-bucket* par votre Compte AWS identifiant et le nom de votre bucket. 

------
#### [ Linux & macOS ]

   ```
   aws iam attach-role-policy \
       --role-name SSMServiceRole \
       --policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
   ```

------
#### [ Windows ]

   ```
   aws iam attach-role-policy ^
       --role-name SSMServiceRole ^
       --policy-arn arn:aws:iam::account-id:policy/amzn-s3-demo-bucket
   ```

------

   (Facultatif) Exécutez la commande suivante SSM Agent pour autoriser Directory Service le nœud géré à accéder en votre nom aux demandes de connexion au domaine. Votre fonction du service requiert uniquement cette politique si vous joignez vos nœuds à un annuaire Microsoft AD.

------
#### [ Linux & macOS ]

   ```
   aws iam attach-role-policy \
       --role-name SSMServiceRole \
       --policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
   ```

------
#### [ Windows ]

   ```
   aws iam attach-role-policy ^
       --role-name SSMServiceRole ^
       --policy-arn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
   ```

------

   (Facultatif) Exécutez la commande suivante pour autoriser l' CloudWatch agent à s'exécuter sur vos nœuds gérés. Cette commande permet de lire des informations sur un nœud et de les y écrire CloudWatch. Votre profil de service n'a besoin de cette politique que si vous utilisez des services tels qu'Amazon EventBridge ou Amazon CloudWatch Logs.

   ```
   aws iam attach-role-policy \
       --role-name SSMServiceRole \
       --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
   ```

------
#### [ Tools for PowerShell ]

**Pour créer une fonction du service IAM pour un environnement hybride et multicloud (AWS Tools for Windows PowerShell)**

1. Installez et configurez les Outils AWS pour PowerShell (Outils pour Windows PowerShell), si ce n'est pas déjà fait.

   Pour plus d'informations, consultez [Installation d' Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).

1. Sur votre machine locale, créez un fichier texte avec un nom tel que `SSMService-Trust.json` avec la politique d'approbation suivante. Assurez-vous d'enregistrer le fichier avec l'extension de fichier `.json`. Assurez-vous de spécifier votre Compte AWS et le Région AWS dans l'ARN dans lequel vous avez créé votre activation hybride.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "",
               "Effect": "Allow",
               "Principal": {
                   "Service": "ssm.amazonaws.com"
               },
               "Action": "sts:AssumeRole",
               "Condition": {
                   "StringEquals": {
                       "aws:SourceAccount": "123456789012"
                   },
                   "ArnEquals": {
                       "aws:SourceArn": "arn:aws:ssm:us-east-1:123456789012:*"
                   }
               }
           }
       ]
   }
   ```

------

1. Ouvrez PowerShell en mode administratif et dans le répertoire où vous avez créé le fichier JSON, exécutez [New- IAMRole](https://docs.aws.amazon.com//powershell/latest/reference/items/Register-IAMRolePolicy.html) comme suit pour créer un rôle de service. Cet exemple crée un rôle nommé `SSMServiceRole`. Vous pouvez choisir un autre nom si vous préférez.

   ```
   New-IAMRole `
       -RoleName SSMServiceRole `
       -AssumeRolePolicyDocument (Get-Content -raw SSMService-Trust.json)
   ```

1. Utilisez [IAMRoleRegister-Policy](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-IAMRolePolicy.html) comme suit pour autoriser le rôle de service que vous avez créé à créer un jeton de session. Ce jeton de session autorise votre nœud géré à exécuter des commandes à l'aide de Systems Manager.
**Note**  
Les politiques que vous ajoutez pour un profil de service pour des nœuds gérés dans un environnement hybride et multicloud sont les mêmes politiques que celles utilisées pour créer un profil d'instance pour des instances EC2. Pour plus d'informations sur les AWS politiques utilisées dans les commandes suivantes, consultez [Configurer les autorisations d'instance requises pour Systems Manager](setup-instance-permissions.md).

   (Obligatoire) Exécutez la commande suivante pour autoriser un nœud géré à utiliser les fonctionnalités AWS Systems Manager de base du service.

   ```
   Register-IAMRolePolicy `
       -RoleName SSMServiceRole `
       -PolicyArn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
   ```

   Si vous avez créé une politique de compartiment S3 personnalisée pour votre rôle de service, exécutez la commande suivante pour permettre à SSM Agent d'accéder aux compartiments que vous avez spécifiés dans la politique. Remplacez *account-id* et *my-bucket-policy-name* par votre Compte AWS identifiant et le nom de votre bucket. 

   ```
   Register-IAMRolePolicy `
       -RoleName SSMServiceRole `
       -PolicyArn arn:aws:iam::account-id:policy/my-bucket-policy-name
   ```

   (Facultatif) Exécutez la commande suivante SSM Agent pour autoriser Directory Service le nœud géré à accéder en votre nom aux demandes de connexion au domaine. Votre rôle de serveur requiert uniquement cette politique si vous joignez vos nœuds à un annuaire Microsoft AD.

   ```
   Register-IAMRolePolicy `
       -RoleName SSMServiceRole `
       -PolicyArn arn:aws:iam::aws:policy/AmazonSSMDirectoryServiceAccess
   ```

   (Facultatif) Exécutez la commande suivante pour autoriser l' CloudWatch agent à s'exécuter sur vos nœuds gérés. Cette commande permet de lire des informations sur un nœud et de les y écrire CloudWatch. Votre profil de service n'a besoin de cette politique que si vous utilisez des services tels qu'Amazon EventBridge ou Amazon CloudWatch Logs.

   ```
   Register-IAMRolePolicy `
       -RoleName SSMServiceRole `
       -PolicyArn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
   ```

------

Passez au [Créer une activation hybride pour enregistrer des nœuds avec Systems Manager](hybrid-activation-managed-nodes.md).

# Créer une activation hybride pour enregistrer des nœuds avec Systems Manager
<a name="hybrid-activation-managed-nodes"></a>

Pour configurer des machines autres que des instances Amazon Elastic Compute Cloud (EC2) en tant que nœuds gérés pour un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types), vous devez créer et appliquer une *activation hybride*. Une fois que l'activation a abouti, vous recevez *immédiatement* un code d'activation et un ID d'activation en haut de la page de la console. Vous spécifiez cette combinaison de code et d'identifiant lors de l'installation AWS Systems Manager SSM Agent sur des machines autres que EC2 pour votre environnement hybride et multicloud. La combinaison code/ID fournit un accès sécurisé au service Systems Manager à partir de vos nœuds gérés.

**Important**  
Systems Manager renvoie immédiatement le code d'activation et l'ID à la console ou la fenêtre de commande, selon la méthode de création de l'activation. Copiez ces informations et stockez-les en lieu sûr. Si vous quittez la console ou fermez la fenêtre de commande, vous risquez de perdre ces informations. Si vous les perdez, vous devrez recréer une activation. 

**À propos des expirations d'activation**  
Une *expiration d'activation* est une fenêtre de temps pendant laquelle vous pouvez enregistrer des machines sur site avec Systems Manager. Une activation expirée n'a aucun impact sur vos serveurs ou sur le VMs fait que vous vous êtes déjà enregistré auprès de Systems Manager. Si une activation expire, vous ne pouvez pas enregistrer d'autres serveurs ou VMs auprès de Systems Manager en utilisant cette activation spécifique. Il vous suffit d'en créer une.

Chaque serveur et chaque VM sur site que vous avez précédemment enregistré(e) reste enregistré(e) comme nœud géré par Systems Manager tant que vous n'aurez pas annulé son enregistrement de manière explicite. Vous pouvez désenregistrer un nœud non géré par EC2 en procédant comme suit :
+ Utilisez l’onglet **Nœuds gérés** dans Fleet Manager dans la console Systems Manager
+ Utilisez la AWS CLI commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html)
+ Utilisez l’action d’API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html).

Pour plus d’informations, consultez les rubriques suivantes
+ [Désenregistrer et réenregistrer un nœud géré (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister)
+ [Désenregistrer et réenregistrer un nœud géré (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister)

**À propos des nœuds gérés**  
Un nœud géré est une machine configurée pour AWS Systems Manager. AWS Systems Manager prend en charge les instances Amazon Elastic Compute Cloud (Amazon EC2), les appareils périphériques et les serveurs sur site VMs ou, VMs y compris dans d'autres environnements cloud. Auparavant, les nœuds gérés étaient tous appelés instances gérées. Le terme *instance* fait désormais référence uniquement aux instances EC2. La [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html)commande a été nommée avant ce changement de terminologie.

**À propos des balises d'activation**  
Si vous créez une activation en utilisant le AWS Command Line Interface (AWS CLI) ou AWS Tools for Windows PowerShell, vous pouvez spécifier des balises. Les balises sont des métadonnées facultatives que vous affectez à une ressource. Les balises vous permettent de classer une ressource de différentes façons, par exemple, par objectif, par propriétaire ou par environnement. Voici un AWS CLI exemple de commande à exécuter dans la région USA Est (Ohio) sur une machine Linux locale qui inclut des balises facultatives.

```
aws ssm create-activation \
  --default-instance-name MyWebServers \
  --description "Activation for Finance department webservers" \
  --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
  --registration-limit 10 \
  --region us-east-2 \
  --tags "Key=Department,Value=Finance"
```

Si vous spécifiez des balises lorsque vous créez une activation, ces balises sont automatiquement affectées à vos nœuds gérés lorsque vous les activez.

Vous ne pouvez pas ajouter ou supprimer des balises dans une activation existante. Si vous ne souhaitez pas attribuer automatiquement des balises à vos serveurs locaux à VMs l'aide d'une activation, vous pouvez y ajouter des balises ultérieurement. Plus précisément, vous pouvez étiqueter vos serveurs sur site et VMs après leur première connexion à Systems Manager. Une fois qu'ils se sont connectés, un ID de nœud géré leur est affecté et ils sont répertoriés dans la console Systems Manager avec un ID dont le préfixe est « mi- ».

**Note**  
Vous ne pouvez pas attribuer des balises à une activation si vous la créez à l'aide de la console Systems Manager. Vous devez le créer à l'aide du AWS CLI ou des outils pour Windows PowerShell.

Si vous ne souhaitez plus gérer un serveur local ou une machine virtuelle (VM) à l'aide de Systems Manager, vous pouvez annuler son enregistrement. Pour plus d'informations, consultez [Annulation de l'enregistrement de nœuds gérés dans un environnement hybride et multicloud](fleet-manager-deregister-hybrid-nodes.md).

**Topics**
+ [Utilisation du AWS Management Console pour créer une activation permettant d'enregistrer des nœuds gérés auprès de Systems Manager](#create-managed-node-activation-console)
+ [Utilisation de la ligne de commande pour créer une activation permettant d’enregistrer des nœuds gérés avec Systems Manager](#create-managed-node-activation-command-line)

## Utilisation du AWS Management Console pour créer une activation permettant d'enregistrer des nœuds gérés auprès de Systems Manager
<a name="create-managed-node-activation-console"></a>

**Créer une activation de nœuds gérés**

1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).

1. Dans le panneau de navigation, choisissez **Hybrid Activations (Activations hybrides)**.

1. Choisissez **Créer une activation**.

   -ou-

   Si c'est la première fois que vous accédez aux **activations hybrides** Région AWS, choisissez **Créer une activation**. 

1. (Facultatif) Dans le champ **Activation description** (Description de l'activation), saisissez une description pour cette activation. Nous vous recommandons de saisir une description si vous prévoyez d'activer un grand nombre de serveurs et VMs.

1. Pour **Limite d'instances**, spécifiez le nombre total de nœuds auprès desquels vous souhaitez vous enregistrer dans AWS le cadre de cette activation. La valeur par défaut est 1 instance.

1. Pour **le rôle IAM**, choisissez une option de rôle de service qui autorise vos serveurs VMs à communiquer AWS Systems Manager dans le cloud :
   + **Option 1** : choisissez **Use the default role created by the system** (Utiliser le rôle par défaut créé par le système) pour utiliser un rôle et une politique gérée fournis par AWS. 
   + **Option 2** : choisissez **Select an existing custom IAM role that has the required permissions** (Sélectionner un rôle IAM personnalisé existant ayant les autorisations requises) pour utiliser le rôle personnalisé facultatif que vous avez créé précédemment. Ce rôle doit avoir une politique de relation d'approbation qui spécifie `"Service": "ssm.amazonaws.com"`. Si votre rôle IAM ne spécifie pas ce principe dans une politique de relation d'approbation, l'erreur suivante s'affiche :

     ```
     An error occurred (ValidationException) when calling the CreateActivation
                                         operation: Not existing role: arn:aws:iam::<accountid>:role/SSMRole
     ```

     Pour plus d'informations sur la création de ce rôle, consultez la page [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](hybrid-multicloud-service-role.md). 

1. Dans le champ **Activation expiry date** (Date d'expiration de l'activation), indiquez une date d'expiration pour l'activation. La date d'expiration doit se situer dans la plage des 30 prochains jours. La valeur par défaut est 24 heures.
**Note**  
Si vous souhaitez enregistrer des nœuds gérés supplémentaires après la date d'expiration, vous devez créer une nouvelle activation. La date d'expiration n'a aucun impact sur les nœuds enregistrés et en cours d'exécution.

1. (Facultatif) Pour le champ **Default instance name** (Nom de l'instance par défaut), spécifiez une valeur de nom d'identification à afficher pour tous les nœuds gérés associés à cette activation. 

1. Choisissez **Créer une activation**. Systems Manager renvoie immédiatement le code d'activation et l'ID à la console. 

## Utilisation de la ligne de commande pour créer une activation permettant d’enregistrer des nœuds gérés avec Systems Manager
<a name="create-managed-node-activation-command-line"></a>

La procédure suivante décrit comment utiliser le AWS Command Line Interface (AWS CLI) (sous Linux ouWindows Server) ou comment Outils AWS pour PowerShell créer une activation de nœud géré.

**Pour créer une activation**

1. Installez et configurez le AWS CLI ou le Outils AWS pour PowerShell, si ce n'est pas déjà fait.

   Pour plus d'informations, consultez la section [Installation ou mise à jour de la version la plus récente de l' AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) et [Installation d' Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).

1. Exécutez la commande suivante pour créer une activation.
**Note**  
Dans la commande suivante, remplacez *region* par vos propres informations. Pour obtenir la liste des *region* valeurs prises en charge, consultez la colonne **Région** dans les [points de terminaison du service Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) dans le *Référence générale d'Amazon Web Services*.
Le rôle que vous spécifiez pour le *iam-role* paramètre doit disposer d'une politique de relation de confiance qui spécifie`"Service": "ssm.amazonaws.com"`. Si votre rôle Gestion des identités et des accès AWS (IAM) ne spécifie pas ce principe dans une politique de relation de confiance, le message d'erreur suivant s'affiche :  

     ```
     An error occurred (ValidationException) when calling the CreateActivation
                                             operation: Not existing role: arn:aws:iam::<accountid>:role/SSMRole
     ```
Pour plus d'informations sur la création de ce rôle, consultez la page [Créer le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud](hybrid-multicloud-service-role.md). 
Pour `--expiration-date`, fournissez une date au format horodatage, `"2021-07-07T00:00:00"` par exemple, pour indiquer la date d'expiration du code d'activation. Vous pouvez spécifier une date jusqu'à 30 jours à l'avance. Si vous ne fournissez pas de date d'expiration, le code d'activation expire sous 24 heures.

------
#### [ Linux & macOS ]

   ```
   aws ssm create-activation \
       --default-instance-name name \
       --iam-role iam-service-role-name \
       --registration-limit number-of-managed-instances \
       --region region \
       --expiration-date "timestamp" \\  
       --tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
   ```

------
#### [ Windows ]

   ```
   aws ssm create-activation ^
       --default-instance-name name ^
       --iam-role iam-service-role-name ^
       --registration-limit number-of-managed-instances ^
       --region region ^
       --expiration-date "timestamp" ^
       --tags "Key=key-name-1,Value=key-value-1" "Key=key-name-2,Value=key-value-2"
   ```

------
#### [ PowerShell ]

   ```
   New-SSMActivation -DefaultInstanceName name `
       -IamRole iam-service-role-name `
       -RegistrationLimit number-of-managed-instances `
       –Region region `
       -ExpirationDate "timestamp" `
       -Tag @{"Key"="key-name-1";"Value"="key-value-1"},@{"Key"="key-name-2";"Value"="key-value-2"}
   ```

------

   Voici un exemple.

------
#### [ Linux & macOS ]

   ```
   aws ssm create-activation \
       --default-instance-name MyWebServers \
       --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances \
       --registration-limit 10 \
       --region us-east-2 \
       --expiration-date "2021-07-07T00:00:00" \
       --tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
   ```

------
#### [ Windows ]

   ```
   aws ssm create-activation ^
       --default-instance-name MyWebServers ^
       --iam-role service-role/AmazonEC2RunCommandRoleForManagedInstances ^
       --registration-limit 10 ^
       --region us-east-2 ^
       --expiration-date "2021-07-07T00:00:00" ^
       --tags "Key=Environment,Value=Production" "Key=Department,Value=Finance"
   ```

------
#### [ PowerShell ]

   ```
   New-SSMActivation -DefaultInstanceName MyWebServers `
       -IamRole service-role/AmazonEC2RunCommandRoleForManagedInstances `
       -RegistrationLimit 10 `
       –Region us-east-2 `
       -ExpirationDate "2021-07-07T00:00:00" `
       -Tag @{"Key"="Environment";"Value"="Production"},@{"Key"="Department";"Value"="Finance"}
   ```

------

   Si l'activation est créée avec succès, le système renvoie immédiatement un code d'activation et un ID.

# Installer SSM Agent sur les nœuds Linux hybrides
<a name="hybrid-multicloud-ssm-agent-install-linux"></a>

Cette rubrique décrit comment procéder à l'installation AWS Systems Manager SSM Agent sur des machines Linux non EC2 (Amazon Elastic Compute Cloud) dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Pour plus d’informations sur l’installation de SSM Agent sur les instances EC2 pour Linux, consultez [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Linux](manually-install-ssm-agent-linux.md).

Avant de commencer, recherchez le code d’activation et l’ID d’activation qui ont été générés au cours du processus d’activation hybride, comme décrit dans [Créer une activation hybride pour enregistrer des nœuds avec Systems Manager](hybrid-activation-managed-nodes.md). Vous indiquez le code et l'ID dans la procédure suivante.

**Pour installer SSM Agent sur des machines non EC2 dans un environnement hybride et multicloud**

1. Connectez-vous à un serveur ou une VM de votre environnement hybride et multicloud.

1. Si vous utilisez un proxy HTTP ou HTTPS, vous devez définir les variables d'environnement `http_proxy` ou `https_proxy` dans la session shell en cours. Si vous n'utilisez pas de proxy, vous pouvez ignorer cette étape.

   Pour un serveur proxy HTTP, saisissez les commandes suivantes sur la ligne de commande :

   ```
   export http_proxy=http://hostname:port
   export https_proxy=http://hostname:port
   ```

   Pour un serveur proxy HTTPS, saisissez les commandes suivantes sur la ligne de commande :

   ```
   export http_proxy=http://hostname:port
   export https_proxy=https://hostname:port
   ```

1. Copiez et collez l'un des blocs de commande suivants dans SSH. Remplacez les valeurs d'espace réservé par le code d'activation et l'identifiant d'activation générés lors du processus d'activation hybride et par l'identifiant du fichier à SSM Agent partir Région AWS duquel vous souhaitez effectuer le téléchargement, puis appuyez sur`Enter`.
**Important**  
Prenez note des informations importantes suivantes :  
L’utilisation de `ssm-setup-cli` pour des installations non EC2 maximise la sécurité de votre installation et de votre configuration Systems Manager.
`sudo` n'est pas nécessaire si vous êtes un utilisateur racine.
Téléchargez `ssm-setup-cli` à partir de Région AWS l'endroit où votre activation hybride a été créée.
`ssm-setup-cli` prend en charge une option `manifest-url` qui détermine la source à partir de laquelle l’agent est téléchargé. Ne spécifiez aucune valeur pour cette option à moins que votre organisation ne l’exige.
Lors de l’enregistrement des instances, n’utilisez que le lien de téléchargement fourni pour `ssm-setup-cli`. `ssm-setup-cli` ne doit pas être stocké séparément pour une utilisation ultérieure.
Vous pouvez utiliser le script fourni [ici](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_linux.sh) pour valider la signature de `ssm-setup-cli`.

   *region*représente l'identifiant d'une région Région AWS prise en charge par AWS Systems Manager, par exemple `us-east-2` pour la région USA Est (Ohio). Pour obtenir la liste des *region* valeurs prises en charge, consultez la colonne **Région** dans les [points de terminaison du service Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) dans le *Référence générale d'Amazon Web Services*.

   De plus, `ssm-setup-cli` inclut les options suivantes :
   + `version` : les valeurs valides sont `latest` et `stable`.
   + `downgrade` : permet de rétrograder SSM Agent à une version antérieure. Spécifiez `true` pour installer une version antérieure de l’agent.
   + `skip-signature-validation` : ignore la validation de signature lors du téléchargement et de l’installation de l’agent.

## Amazon Linux 2, RHEL 7.x et Oracle Linux
<a name="cent-7"></a>

```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```

## RHEL 8.x
<a name="cent-8"></a>

```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/linux_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```

## Debian Server
<a name="deb"></a>

```
mkdir /tmp/ssm
curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
sudo chmod +x /tmp/ssm/ssm-setup-cli
sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
```

## Ubuntu Server
<a name="ubu"></a>
+ **Utilisation de packages .deb**

  ```
  mkdir /tmp/ssm
  curl https://amazon-ssm-region.s3.region.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
  sudo chmod +x /tmp/ssm/ssm-setup-cli
  sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region"
  ```
+ **Utilisation de packages Snap**

  Vous n'avez pas besoin de spécifier une URL pour le téléchargement, car la commande `snap` télécharge automatiquement l'agent à partir de la [boutique d'applications Snap](https://snapcraft.io/amazon-ssm-agent) à l'adresse [https://snapcraft.io](https://snapcraft.io).

  Sur Ubuntu Server 20.04, 18.04 et 16.04 LTS, les fichiers du programme d’installation SSM Agent, y compris les fichiers binaires et les fichiers de configuration de l’agent, sont stockés dans le répertoire suivant : `/snap/amazon-ssm-agent/current/`. Si vous apportez des modifications aux fichiers de configuration de ce répertoire, vous devez copier ces fichiers du répertoire `/snap` vers le répertoire `/etc/amazon/ssm/`. Les fichiers journaux et de bibliothèque n'ont pas changé (`/var/lib/amazon/ssm`, `/var/log/amazon/ssm`).

  ```
  sudo snap install amazon-ssm-agent --classic
  sudo systemctl stop snap.amazon-ssm-agent.amazon-ssm-agent.service
  sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region" 
  sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
  ```
**Important**  
Le canal *candidat* dans le magasin de Snaps contient la dernière version de l'SSM Agent ; pas le canal stable. Si vous souhaitez suivre les informations de version de SSM Agent sur le canal candidat, exécutez la commande suivante sur vos nœuds gérés 64 bits Ubuntu Server 18.04 et 16.04 LTS.  

  ```
  sudo snap switch --channel=candidate amazon-ssm-agent
  ```

La commande télécharge et installe SSM Agent sur la machine activée par un système hybride dans votre environnement hybride et multicloud. La commande arrête SSM Agent, puis enregistre la machine auprès du service Systems Manager. La machine est désormais un nœud géré. Les instances Amazon EC2 configurées pour Systems Manager sont également des nœuds gérés. Pourtant, dans la console Systems Manager, vos nœuds activés par un système hybride se distinguent des instances Amazon EC2 par le préfixe « mi- ».

Passez au [Installer SSM Agent sur les nœuds hybrides Windows Server](hybrid-multicloud-ssm-agent-install-windows.md).

## Configuration de la rotation automatique de la clé privée
<a name="ssm-agent-hybrid-private-key-rotation-linux"></a>

Pour renforcer votre niveau de sécurité, vous pouvez configurer AWS Systems Manager Agent (SSM Agent) pour qu'il fasse automatiquement pivoter la clé privée pour votre environnement hybride et multicloud. Vous pouvez accéder à cette fonction en utilisant la version 3.0.1031.0 ou ultérieure de l'SSM Agent. Procédez comme suit pour activer cette fonction.

**Pour configurer SSM Agent de sorte à effectuer une rotation de la clé privée d'un environnement hybride et multicloud**

1. Accédez à `/etc/amazon/ssm/` sur une machine Linux ou à `C:\Program Files\Amazon\SSM` sur une machine Windows.

1. Copiez le contenu de `amazon-ssm-agent.json.template` vers un nouveau fichier appelé `amazon-ssm-agent.json`. Enregistrez `amazon-ssm-agent.json` dans le même répertoire que `amazon-ssm-agent.json.template`.

1. Recherchez `Profile`, `KeyAutoRotateDays`. Saisissez le nombre de jours qui doit séparer les rotations automatiques de clé privée. 

1. Redémarrez SSM Agent.

Chaque fois que vous modifiez la configuration, redémarrez l'SSM Agent.

Vous pouvez personnaliser d'autres fonctions de l'SSM Agent en suivant la même procédure. Pour une up-to-date liste des propriétés de configuration disponibles et de leurs valeurs par défaut, consultez la section [Définitions des propriétés de configuration](https://github.com/aws/amazon-ssm-agent#config-property-definitions). 

## Désenregistrer et réenregistrer un nœud géré (Linux)
<a name="systems-manager-install-managed-linux-deregister-reregister"></a>

Vous pouvez annuler l'enregistrement d'un nœud géré activé de manière hybride en appelant l'opération [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html)API depuis Windows AWS CLI ou depuis Tools for Windows. PowerShell Voici un exemple de commande de l'interface de ligne de commande :

`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`

Pour supprimer les informations d’enregistrement restantes pour l’agent, supprimez la clé `IdentityConsumptionOrder` du fichier `amazon-ssm-agent.json`. Ensuite, exécutez l’une des commandes suivantes selon votre type d’instance.

Sur les nœuds Ubuntu Server où SSM Agent a été installé à l’aide de packages Snap :

```
sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -clear
```

Pour toutes les autres installations Linux :

```
amazon-ssm-agent -register -clear
```

**Note**  
Vous pouvez réenregistrer un serveur local, un appareil de périphérie ou une machine virtuelle en utilisant le même code d’activation et le même ID, tant que vous n’avez pas atteint la limite d’instances pour le code et l’ID d’activation désignés. Vous pouvez vérifier la limite d’instances pour un code et un ID d’activation en appelant l’API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) à l’aide d’ AWS CLI. Après avoir exécuté la commande, vérifiez que la valeur de `RegistrationCount` ne dépasse pas `RegistrationLimit`. Si c’est le cas, vous devez utiliser un ID et un code d’activation différents.

**Pour réenregistrer un nœud géré sur une machine Linux non EC2**

1. Connectez-vous à votre machine.

1. Exécutez la commande suivante. Veillez à remplacer les valeurs d’espace réservé par le code d’activation et l’ID d’activation générés lors de la création d’une activation de nœuds gérés, et par l’identifiant de la région depuis laquelle vous souhaitez télécharger SSM Agent.

   ```
   echo "yes" | sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "region
   ```

## Résolution des problèmes d'installation de SSM Agent sur des machines Linux non EC2
<a name="systems-manager-install-managed-linux-troubleshooting"></a>

Utilisez les informations suivantes pour résoudre les problèmes liés à l'installation de SSM Agent sur des machines Linux activées par un système hybride dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types).

### Vous recevez un DeliveryTimedOut message d'erreur
<a name="systems-manager-install-managed-linux-troubleshooting-delivery-timed-out"></a>

**Problème** : lors de la configuration d'une machine en Compte AWS tant que nœud géré pour une machine séparée Compte AWS, vous recevez `DeliveryTimedOut` après avoir exécuté les commandes d'installation SSM Agent sur la machine cible.

**Solution** : `DeliveryTimedOut` est le code de réponse attendu pour ce scénario. La commande pour installer l'SSM Agent sur le nœud cible modifie l'ID de nœud du nœud source. Comme l'ID de nœud a changé, le nœud source n'est pas en mesure de répondre au nœud cible que la commande a échoué, s'est terminée ou a expiré lors de l'exécution.

### Impossible de charger les associations de nœuds
<a name="systems-manager-install-managed-linux-troubleshooting-associations"></a>

**Problème** : après avoir exécuté les commandes d'installation, l'erreur suivante s'affiche dans les journaux d'erreurs de l'SSM Agent :

`Unable to load instance associations, unable to retrieve associations unable to retrieve associations error occurred in RequestManagedInstanceRoleToken: MachineFingerprintDoesNotMatch: Fingerprint doesn't match`

Cette erreur s'affiche lorsque l'ID de la machine ne reste pas après un redémarrage.

**Solution** : pour résoudre ce problème, exécutez la commande suivante. Cette commande force l'ID de la machine à rester après un redémarrage.

```
umount /etc/machine-id
systemd-machine-id-setup
```

# Installer SSM Agent sur les nœuds hybrides Windows Server
<a name="hybrid-multicloud-ssm-agent-install-windows"></a>

Cette rubrique décrit comment procéder à l'installation AWS Systems Manager SSM Agent sur Windows Server des machines dans un environnement [hybride et multicloud](operating-systems-and-machine-types.md#supported-machine-types). Pour plus d'informations sur l'installation de SSM Agent sur les instances EC2 pour Windows Server, consultez [Installation et désinstallation manuelles de SSM Agent sur les instances EC2 pour Windows Server](manually-install-ssm-agent-windows.md).

Avant de commencer, recherchez le code d’activation et l’ID d’activation qui ont été générés au cours du processus d’activation hybride, comme décrit dans [Créer une activation hybride pour enregistrer des nœuds avec Systems Manager](hybrid-activation-managed-nodes.md). Vous indiquez le code et l'ID dans la procédure suivante.

**Pour installer SSM Agent sur des machines Windows Server non EC2 dans un environnement hybride et multicloud**

1. Connectez-vous à un serveur ou une VM de votre environnement hybride et multicloud.

1. Si vous utilisez un proxy HTTP ou HTTPS, vous devez définir les variables d'environnement `http_proxy` ou `https_proxy` dans la session shell en cours. Si vous n'utilisez pas de proxy, vous pouvez ignorer cette étape.

   Pour un serveur proxy HTTP, définissez cette variable :

   ```
   http_proxy=http://hostname:port
   https_proxy=http://hostname:port
   ```

   Pour un serveur proxy HTTPS, définissez cette variable :

   ```
   http_proxy=http://hostname:port
   https_proxy=https://hostname:port
   ```

   Pour PowerShell, configurez les paramètres du INet proxy Win :

   ```
   [System.Net.WebRequest]::DefaultWebProxy
   
   $proxyServer = "http://hostname:port"
   $proxyBypass = "169.254.169.254"
   $WebProxy = New-Object System.Net.WebProxy($proxyServer,$true,$proxyBypass)
   
   [System.Net.WebRequest]::DefaultWebProxy = $WebProxy
   ```
**Note**  
La configuration INet du proxy Win est requise pour les PowerShell opérations. Pour de plus amples informations, veuillez consulter [Paramètres de proxy de l'SSM Agent et services Systems Manager](configure-proxy-ssm-agent-windows.md#ssm-agent-proxy-services).

1. Ouvrez Windows PowerShell en mode élevé (administratif).

1. Copiez et collez le bloc de commande suivant dans les Windows PowerShell. Remplacez chaque *example resource placeholder* par vos propres informations. Par exemple, le code d'activation et l'identifiant d'activation générés lorsque vous créez une activation hybride, et avec l'identifiant du fichier à SSM Agent partir Région AWS duquel vous souhaitez effectuer le téléchargement.
**Important**  
Prenez note des informations importantes suivantes :  
L’utilisation de `ssm-setup-cli` pour des installations non EC2 maximise la sécurité de votre installation et de votre configuration Systems Manager.
`ssm-setup-cli` prend en charge une option `manifest-url` qui détermine la source à partir de laquelle l’agent est téléchargé. Ne spécifiez aucune valeur pour cette option à moins que votre organisation ne l’exige.
Vous pouvez utiliser le script fourni [ici](https://github.com/aws/amazon-ssm-agent/blob/mainline/Tools/src/setupcli_data_integrity_windows.ps1) pour valider la signature de `ssm-setup-cli`.
Lors de l’enregistrement des instances, n’utilisez que le lien de téléchargement fourni pour `ssm-setup-cli`. `ssm-setup-cli` ne doit pas être stocké séparément pour une utilisation ultérieure.

   *region*représente l'identifiant d'une région Région AWS prise en charge par AWS Systems Manager, par exemple `us-east-2` pour la région USA Est (Ohio). Pour obtenir la liste des *region* valeurs prises en charge, consultez la colonne **Région** dans les [points de terminaison du service Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) dans le *Référence générale d'Amazon Web Services*.

   De plus, `ssm-setup-cli` inclut les options suivantes :
   + `version` : les valeurs valides sont `latest` et `stable`.
   + `downgrade` : rétablit une version antérieure de l’agent.
   + `skip-signature-validation` : ignore la validation de signature lors du téléchargement et de l’installation de l’agent.

------
#### [ 64-bit ]

   ```
   [System.Net.ServicePointManager]::SecurityProtocol = 'TLS12'
   $code = "activation-code"
   $id = "activation-id"
   $region = "us-east-1"
   $dir = $env:TEMP + "\ssm"
   New-Item -ItemType directory -Path $dir -Force
   cd $dir
   (New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/ssm-setup-cli.exe", $dir + "\ssm-setup-cli.exe")
   ./ssm-setup-cli.exe -register -activation-code="$code" -activation-id="$id" -region="$region"
   Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
   Get-Service -Name "AmazonSSMAgent"
   ```

------

1. Appuyez sur `Enter`.

**Note**  
Si la commande échoue, vérifiez que vous exécutez la dernière version d’ Outils AWS pour PowerShell.

La commande exécute les opérations suivantes : 
+ Télécharge et installe SSM Agent sur la machine.
+ Enregistre la machine avec le service Systems Manager.
+ Renvoie à la demande une réponse semblable à ce qui suit :

  ```
      Directory: C:\Users\ADMINI~1\AppData\Local\Temp\2
  
  
  Mode                LastWriteTime         Length Name
  ----                -------------         ------ ----
  d-----       07/07/2018   8:07 PM                ssm
  {"ManagedInstanceID":"mi-008d36be46EXAMPLE","Region":"us-east-2"}
  
  Status      : Running
  Name        : AmazonSSMAgent
  DisplayName : Amazon SSM Agent
  ```

La machine est désormais un *nœud géré*. Ces nœuds gérés sont à présent identifiés avec le préfixe « mi- ». Vous pouvez afficher les nœuds gérés sur la page des **nœuds gérés** dansFleet Manager, à l'aide de la AWS CLI commande [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html)ou de la commande API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceInformation.html).

## Configuration de la rotation automatique de la clé privée
<a name="ssm-agent-hybrid-private-key-rotation-windows"></a>

Pour renforcer votre niveau de sécurité, vous pouvez configurer AWS Systems Manager Agent (SSM Agent) pour qu'il fasse automatiquement pivoter la clé privée dans un environnement hybride et multicloud. Vous pouvez accéder à cette fonction en utilisant la version 3.0.1031.0 ou ultérieure de l'SSM Agent. Procédez comme suit pour activer cette fonction.

**Pour configurer SSM Agent de sorte à effectuer une rotation de la clé privée d'un environnement hybride et multicloud**

1. Accédez à `/etc/amazon/ssm/` sur une machine Linux ou à `C:\Program Files\Amazon\SSM` sur une machine Windows Server.

1. Copiez le contenu de `amazon-ssm-agent.json.template` vers un nouveau fichier appelé `amazon-ssm-agent.json`. Enregistrez `amazon-ssm-agent.json` dans le même répertoire que `amazon-ssm-agent.json.template`.

1. Recherchez `Profile`, `KeyAutoRotateDays`. Saisissez le nombre de jours qui doit séparer les rotations automatiques de clé privée. 

1. Redémarrez SSM Agent.

Chaque fois que vous modifiez la configuration, redémarrez l'SSM Agent.

Vous pouvez personnaliser d'autres fonctions de l'SSM Agent en suivant la même procédure. Pour une up-to-date liste des propriétés de configuration disponibles et de leurs valeurs par défaut, consultez la section [Définitions des propriétés de configuration](https://github.com/aws/amazon-ssm-agent#config-property-definitions). 

## Désenregistrer et réenregistrer un nœud géré (Windows Server)
<a name="systems-manager-install-managed-win-deregister-reregister"></a>

Vous pouvez annuler l'enregistrement d'un nœud géré en appelant l'opération [DeregisterManagedInstance](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeregisterManagedInstance.html)API depuis Windows AWS CLI ou depuis Tools for Windows. PowerShell Voici un exemple de commande de l'interface de ligne de commande :

`aws ssm deregister-managed-instance --instance-id "mi-1234567890"`

Pour supprimer les informations d’enregistrement restantes pour l’agent, supprimez la clé `IdentityConsumptionOrder` du fichier `amazon-ssm-agent.json`. Ensuite, exécutez la commande suivante :

`amazon-ssm-agent -register -clear`

**Note**  
Vous pouvez réenregistrer un serveur local, un appareil de périphérie ou une machine virtuelle en utilisant le même code d’activation et le même ID, tant que vous n’avez pas atteint la limite d’instances pour le code et l’ID d’activation désignés. Vous pouvez vérifier la limite d’instances pour un code et un ID d’activation en appelant l’API [describe-activations](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-activations.html) à l’aide d’ AWS CLI. Après avoir exécuté la commande, vérifiez que la valeur de `RegistrationCount` ne dépasse pas `RegistrationLimit`. Si c’est le cas, vous devez utiliser un ID et un code d’activation différents.

**Réenregistrer un nœud géré sur une machine hybride Windows Server**

1. Connectez-vous à votre machine.

1. Exécutez la commande suivante. Veillez à remplacer les valeurs d’espace réservé par le code d’activation et l’ID d’activation générés lors de la création d’une activation hybride, et par l’identifiant de la région depuis laquelle vous souhaitez télécharger SSM Agent.

   ```
   $dir = $env:TEMP + "\ssm"
   cd $dir
   Start-Process ./ssm-setup-cli.exe -ArgumentList @(
       "-register",
       "-activation-code=$code",
       "-activation-id=$id",
       "-region=$region"
   ) -Wait -NoNewWindow
   ```