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ésoudre les problèmes de connexion à votre instance Amazon EC2 Linux Les informations suivantes et les erreurs courantes peuvent vous aider à résoudre les problèmes de connexion à votre instance Linux. **Topics** + [Causes courantes des problèmes de connexion](#TroubleshootingInstancesCommonCauses) + [Erreur de connexion à votre instance : connexion expirée](#TroubleshootingInstancesConnectionTimeout) + [Erreur : impossible de charger la clé... Attente : N'IMPORTE QUELLE CLÉ PRIVÉE](#troubleshoot-instance-connect-key-file) + [Erreur : clé de l'utilisateur non reconnue par le serveur](#TroubleshootingInstancesServerError) + [Erreur : autorisation refusée ou connexion fermée par [instance] port 22](#TroubleshootingInstancesConnectingSSH) + [Erreur : fichier de clé privée non protégé](#troubleshoot-unprotected-key) + [Erreur : La clé privée doit commencer par « -----BEGIN RSA PRIVATE KEY----- » et se terminer par « -----END RSA PRIVATE KEY----- »](#troubleshoot-private-key-file-format) + [Erreur : échec de la vérification de la clé d’hôte](#troubleshoot-host-key-verification-failed) + [Erreur : le serveur a refusé notre clé *ou* Aucune méthode d'authentification prise en charge disponible](#TroubleshootingInstancesConnectingPuTTY) + [Impossible d'envoyer une commande ping à l'instance](#troubleshoot-instance-ping) + [Erreur : le serveur a fermé la connexion réseau de manière inopinée](#troubleshoot-ssh) + [Erreur : échec de la validation de la clé d'hôte pour EC2 Instance Connect](#troubleshoot-host-key-validation) + [Impossible de se connecter à une instance Ubuntu à l'aide de EC2 Instance Connect](#troubleshoot-eic-ubuntu) + [J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ?](#replacing-lost-key-pair) ## Causes courantes des problèmes de connexion Nous vous recommandons de commencer à résoudre les problèmes de connexion aux instances en vérifiant que vous avez correctement effectué les tâches suivantes. **Vérifiez le nom d'utilisateur de votre instance** Vous pouvez vous connecter à votre instance en utilisant le nom d'utilisateur de votre compte utilisateur ou le nom d'utilisateur par défaut de l'AMI que vous avez utilisée pour lancer votre instance. + **Obtenez le nom d’utilisateur de votre compte utilisateur.** Pour plus d’informations sur la création d’un compte utilisateur, consultez [Gérez les utilisateurs du système sur votre instance Amazon EC2 Linux](managing-users.md). + **Obtenir le nom d’utilisateur par défaut pour l’AMI que vous avez utilisée pour lancer votre instance** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) **Vérifiez que les règles de votre groupe de sécurité autorisent le trafic** Vérifiez que le groupe de sécurité associé à votre instance autorise le trafic SSH entrant à partir de votre adresse IP. Le groupe de sécurité par défaut pour le VPC n'autorise pas le trafic SSH entrant par défaut. Le groupe de sécurité créé par l'assistant de lancement d'instance autorise le trafic SSH entrant par défaut. Pour savoir comment ajouter une règle pour le trafic SSH entrant vers votre instance Linux, consultez [Règles pour la connexion à des instances à partir de votre ordinateur](security-group-rules-reference.md#sg-rules-local-access). Pour connaître les étapes à vérifier, consultez [Erreur de connexion à votre instance : connexion expirée](#TroubleshootingInstancesConnectionTimeout). **Vérifiez que votre instance est prête** Après avoir lancé une instance, il peut s'écouler quelques minutes avant que l'instance ne soit prête à accepter des demandes de connexion. Vérifiez votre instance pour vous assurer qu'elle est en cours d'exécution et qu'elle a réussi ses vérifications d'état. 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation, choisissez **instances**, puis sélectionnez votre instance. 1. Vérifiez les paramètres suivants : 1. Dans la colonne **État de l'instance**, vérifiez que l'état de votre instance est `running`. 1. Dans la colonne **Contrôle des statuts**, vérifiez que votre instance a passé avec succès tous les contrôles de statut. **Vérifiez que vous avez répondu à toutes les conditions préalables pour vous connecter.** Assurez-vous de disposer de toutes les informations dont vous avez besoin pour vous connecter. Pour de plus amples informations, veuillez consulter [Se connecter à votre instance Linux à l’aide de SSH](connect-to-linux-instance.md). **Connexion à partir de Linux ou macOS X** Si le système d'exploitation de votre ordinateur local est Linux ou macOS X, vérifiez les conditions préalables spécifiques à la connexion à une instance Linux suivantes : + [Client SSH](connect-linux-inst-ssh.md) + [EC2 Instance Connect](connect-linux-inst-eic.md) + [AWS Systems Manager Gestionnaire de sessions](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) **Connexion à partir de Windows** Si le système d'exploitation de votre ordinateur local est Windows, vérifiez les conditions préalables spécifiques à la connexion à une instance Linux suivantes : + [OpenSSH](connect-linux-inst-ssh.md) + [PuTTY](connect-linux-inst-from-windows.md) + [AWS Systems Manager Gestionnaire de sessions](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) + [WSL (Windows Subsystem for Linux)](connect-linux-inst-ssh.md) **Vérifiez si l'instance est une instance gérée** Les connexions initiées par l'utilisateur aux instances gérées ne sont pas autorisées. Pour déterminer si l'instance est gérée, recherchez le champ **Géré** correspondant à l'instance. Si la valeur est **vraie**, il s'agit d'une instance gérée. Pour de plus amples informations, veuillez consulter [Instances gérées Amazon EC2](amazon-ec2-managed-instances.md). ## Erreur de connexion à votre instance : connexion expirée Si vous essayez de vous connecter à votre instance et vous obtenez le message d'erreur `Network error: Connection timed out` ou `Error connecting to [instance], reason: -> Connection timed out: connect`, essayez ce qui suit : **Vérifiez les règles du groupe de sécurité.** Vous avez besoin d'une règle de groupe de sécurité qui autorise le trafic entrant depuis l' IPv4 adresse publique de votre ordinateur local sur le port approprié. 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation, choisissez **instances**, puis sélectionnez votre instance. 1. Sous l'onglet **Sécurité** au bas de la page de la console, sous **Règles entrantes**, vérifiez la liste des règles en vigueur pour l'instance sélectionnée. Vérifiez qu'il existe une règle qui autorise le trafic de votre ordinateur local vers le port 22 (SSH). Si votre groupe de sécurité ne possède pas de règle qui permet le trafic entrant à partir de votre ordinateur local, ajoutez une règle à votre règle de sécurité. Pour de plus amples informations, veuillez consulter [Règles pour la connexion à des instances à partir de votre ordinateur](security-group-rules-reference.md#sg-rules-local-access). 1. Pour connaître la règle qui autorise le trafic entrant, consultez la**Source**. Si la valeur est une adresse IP unique et si l'adresse IP n'est pas statique, une nouvelle adresse IP sera attribuée chaque fois que vous redémarrerez votre ordinateur. Cela aura pour conséquence que la règle n'inclut pas le trafic d'adresses IP de votre ordinateur. Il se peut que l'adresse IP ne soit pas statique si votre ordinateur est sur un réseau d'entreprise, si vous vous connectez via un fournisseur de services Internet (ISP), ou si l'adresse IP de votre ordinateur est dynamique et change chaque fois que vous redémarrez votre ordinateur. Pour vous assurer que votre règle de groupe de sécurité autorise le trafic entrant provenant de votre ordinateur local, au lieu de spécifier une adresse IP unique pour**Source**, au lieu de spécifier la plage d'adresses IP utilisées par vos ordinateurs clients. Pour plus d'informations sur les règles des groupes de sécurité, consultez la rubrique [Règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) dans le *Guide de l'utilisateur de Amazon VPC*. **Vérifiez la table de routage pour le sous-réseau.** Vous avez besoin d'un itinéraire qui envoie tout le trafic destiné à l'extérieur du VPC vers la passerelle Internet du VPC. 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation, choisissez **instances**, puis sélectionnez votre instance. 1. Sous l'onglet **Mise en réseau**, notez les valeurs de l'**ID VPC** et de l'**ID de sous-réseau**. 1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Dans le panneau de navigation, choisissez **Passerelles Internet**. Vérifiez qu'il existe une passerelle Internet attachée à votre VPC. Sinon, choisissez **Créer une passerelle Internet**, entrez un nom pour la passerelle Internet et choisissez **Créer une passerelle Internet**. Ensuite, pour la passerelle Internet que vous avez créée, choisissez **Actions**, **Attacher au VPC**, sélectionnez votre VPC, puis choisissez **Attacher la passerelle Internet** pour l'attacher à votre VPC. 1. Dans le panneau de navigation, sélectionnez **Sous-réseaux**, puis sélectionnez votre sous-réseau. 1. Dans l'onglet **Table de routage**, vérifiez qu'il existe une route avec `0.0.0.0/0` comme destination et la passerelle Internet pour votre VPC comme cible. Si vous vous connectez à votre instance à l'aide de son IPv6 adresse, vérifiez qu'il existe un itinéraire pour tout le IPv6 trafic (`::/0`) qui pointe vers la passerelle Internet. Sinon, procédez comme suit : 1. Choisissez l’ID de la table de routage (rtb-*xxxxxxxx*) pour accéder à cette dernière. 1. Dans l’onglet **Routes**, choisissez **Edit routes (Modifier les routes)**. Choisissez **Add route (Ajouter une route)** et utilisez `0.0.0.0/0` comme destination et la passerelle Internet comme cible. Pour IPv6, choisissez **Ajouter un itinéraire**, utilisez `::/0` comme destination et la passerelle Internet comme cible. 1. Choisissez **Save routes (Enregistrer les routes)**. **Vérifiez la liste de contrôle d'accès (ACL) du réseau pour le sous-réseau.** Le réseau ACLs doit autoriser le trafic SSH entrant depuis votre adresse IP locale sur le port 22. Elles doivent également autoriser le trafic sortant vers les ports éphémères (1024-65535). 1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Dans le volet de navigation, choisissez **Subnets**. 1. Sélectionnez votre sous-réseau. 1. Dans la page **ACL réseau**, pour **Règles entrantes**, vérifiez que les règles autorisent le trafic entrant à partir de votre ordinateur sur le port requis. Sinon, supprimez ou modifiez la règle qui bloque le trafic. 1. Pour **Règles sortantes**, vérifiez que les règles autorisent le trafic vers votre ordinateur sur les ports éphémères. Sinon, supprimez ou modifiez la règle qui bloque le trafic. **Si votre ordinateur se trouve sur un réseau d'entreprise** Demandez à votre administrateur réseau si le pare-feu interne autorise le trafic entrant et sortant de votre ordinateur sur le port 22. Si votre ordinateur est équipé d'un pare-feu, vérifiez qu'il autorise le trafic entrant et sortant de votre ordinateur sur le port 22. **Vérifiez que votre instance possède une IPv4 adresse publique.** Si non, vous pouvez associer une adresse IP Elastic à votre instance. Pour de plus amples informations, veuillez consulter [Adresses IP élastiques](elastic-ip-addresses-eip.md). **Vérifiez la charge de l'UC sur votre instance. Il se peut que le serveur soit surchargé.** AWS fournit automatiquement des données telles que CloudWatch les métriques Amazon et le statut de l'instance, que vous pouvez utiliser pour connaître la charge du processeur de votre instance et, si nécessaire, ajuster la manière dont vos charges sont gérées. Pour de plus amples informations, veuillez consulter [Surveillez vos instances à l'aide de CloudWatch](using-cloudwatch.md). + Si votre charge est variable, vous pouvez automatiquement effectuer des mises à l'échelle ascendantes et descendantes de vos instances en utilisant l'[Auto Scaling](https://aws.amazon.com/autoscaling/) et l'[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/). + Si votre charge augmente régulièrement, vous pouvez passer à un type d'instance plus important. Pour de plus amples informations, veuillez consulter [Changements de type d'instance Amazon EC2](ec2-instance-resize.md). **Pour vous connecter à votre instance à l'aide d'une IPv6 adresse, vérifiez les points suivants :** + Votre sous-réseau doit être associé à une table de routage comportant une route pour le IPv6 trafic (`::/0`) vers une passerelle Internet. + Les règles de votre groupe de sécurité doivent autoriser le trafic entrant depuis votre IPv6 adresse locale sur le port 22. + Les règles ACL de votre réseau doivent autoriser le trafic entrant et sortant IPv6 . + Si vous avez lancé votre instance à partir d'une ancienne AMI, elle n'est peut-être pas configurée pour DHCPv6 (les IPv6 adresses ne sont pas automatiquement reconnues sur l'interface réseau). Pour plus d'informations, consultez la section [Configurer IPv6 sur vos instances](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html#vpc-migrate-ipv6-dhcpv6) dans le guide de l'*utilisateur Amazon VPC*. + Votre ordinateur local doit avoir une IPv6 adresse et doit être configuré pour être utilisé IPv6. ## Erreur : impossible de charger la clé... Attente : N'IMPORTE QUELLE CLÉ PRIVÉE Si vous essayez de vous connecter à votre instance et obtenez le message d'erreur `unable to load key ... Expecting: ANY PRIVATE KEY`, le fichier dans lequel la clé privée est stockée est mal configuré. Si le fichier de clé privée se termine par `.pem`, il est peut-être toujours mal configuré. Une cause possible de configuration incorrecte d'un fichier de clé privée est l'absence d'un certificat. **Si le fichier de clé privée est mal configuré, suivez ces étapes pour corriger l'erreur.** 1. Créez une nouvelle paire de clés. Pour de plus amples informations, veuillez consulter [Créer une paire de clés à l’aide d’Amazon EC2](create-key-pairs.md#having-ec2-create-your-key-pair). **Note** Sinon, vous pouvez créer une nouvelle key pair à l'aide d'un outil tiers. Pour de plus amples informations, veuillez consulter [Créer une paire de clés à l’aide d’un outil tiers et importer la clé publique dans Amazon EC2](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws). 1. Ajoutez la nouvelle paire de clés à votre instance. Pour de plus amples informations, veuillez consulter [J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ?](#replacing-lost-key-pair). 1. Connectez-vous à votre instance à l'aide de la nouvelle paire de clés. ## Erreur : clé de l'utilisateur non reconnue par le serveur **Si vous utilisez SSH pour vous connecter à votre instance** + Utilisez `ssh -vvv` pour obtenir des informations très détaillées sur le débogage en vous connectant : ``` ssh -vvv -i path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com ``` L'exemple de données de sortie suivant montre que vous pouvez voir si vous étiez en train de vous connecter à votre instance avec une clé qui n'était pas reconnue par le serveur. ``` open/ANT/myusername/.ssh/known_hosts). debug2: bits set: 504/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: boguspem.pem ((nil)) debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: boguspem.pem debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey: RSA 9c:4c:bc:0c:d0:5c:c7:92:6c:8e:9b:16:e4:43:d8:b2 debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). ``` **Si vous utilisez PuTTY pour vous connecter à votre instance** + Vérifiez que votre fichier de clé privée (.pem) a été converti au format reconnu par PuTTY (.ppk). Pour plus d'informations sur la conversion de votre clé privée, consultez [Connectez-vous à votre instance Linux à l’aide de PuTTY](connect-linux-inst-from-windows.md). **Note** Dans PuTTYgen, chargez votre fichier de clé privée et sélectionnez **Enregistrer la clé privée** plutôt que **Générer**. + Vérifiez que vous vous connectez avec le nom d'utilisateur approprié pour votre AMI. Saisissez le nom d'utilisateur dans la case **Nom d'hôte** de la fenêtre **Configuration de PuTTY**. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html) + Vérifiez que vous avez une règle entrante de groupe de sécurité pour permettre le trafic entrant vers le port approprié. Pour de plus amples informations, veuillez consulter [Règles pour la connexion à des instances à partir de votre ordinateur](security-group-rules-reference.md#sg-rules-local-access). ## Erreur : autorisation refusée ou connexion fermée par [instance] port 22 Si vous vous connectez à votre instance à l'aide de SSH et que vous obtenez l'une des erreurs suivantes : `Host key not found in [directory]`, `Permission denied (publickey)`, `Authentication failed, permission denied` ou `Connection closed by [instance] port 22`, vérifiez que vous vous connectez avec le nom d'utilisateur approprié pour votre AMI *et* que vous avez indiqué le bonne clé privée (fichier `.pem)` pour votre instance). Les noms d'utilisateur appropriés sont les suivants : | AMI utilisée pour lancer l’instance | Nom d’utilisateur par défaut | | --- | --- | | Amazon Linux | ec2-user | | CentOS | centos ou ec2-user | | Debian | admin | | Fedora | fedora ou ec2-user | | FreeBSD | ec2-user | | RHEL | ec2-user ou root | | SUSE | ec2-user ou root | | Ubuntu | ubuntu | | Oracle | ec2-user | | Bitnami | bitnami | | Rocky Linux | rocky | | Autre | Vérifiez auprès du fournisseur de l'AMI | Pa exemple, pour utiliser un client SSH et vous connecter à une instance Amazon Linux, utilisez la commande suivante : ``` ssh -i /path/key-pair-name.pem instance-user-name@ec2-203-0-113-25.compute-1.amazonaws.com ``` Confirmez que vous utilisez le fichier de clé privée qui correspond à la paire de clés que vous avez sélectionnée lorsque vous avez lancé l'instance. 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Dans le panneau de navigation, choisissez **Instances**, puis sélectionnez votre instance. 1. Sous l'onglet **Détails**, sous **Détails de l'instance**, vérifiez la valeur **Nom de la paire de clés**. 1. Si vous n'avez pas spécifié une paire de clés lorsque vous avez lancé l'instance, vous pouvez mettre fin à l'instance et lancer une nouvelle instance en vous assurant de spécifier une paire de clés. S'il s'agit d'une instance que vous avez utilisée, mais que vous n'avez plus le fichier `.pem` pour votre paire de clés, vous pouvez remplacer la paire de clés par une nouvelle. Pour de plus amples informations, veuillez consulter [J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ?](#replacing-lost-key-pair). Si vous avez généré votre propre paire de clés, assurez-vous que votre générateur de clés est configuré pour créer des clés RSA. Les clés DSA ne sont pas acceptées. Si vous obtenez une erreur `Permission denied (publickey)` et qu'aucune des réponses ci-dessus ne s'applique (par exemple, vous avez pu vous connecter précédemment), les autorisations sur le répertoire de base de votre instance a peut-être été modifiées. Les autorisations pour `/home/instance-user-name/.ssh/authorized_keys` doivent être limitées au propriétaire uniquement. **Pour vérifier les autorisations sur votre instance** 1. Arrêtez votre instance et détachez le volume racine. Pour de plus amples informations, veuillez consulter [Arrêtez et démarrez des instances Amazon EC2](Stop_Start.md). 1. Lancez une instance temporaire dans la même zone de disponibilité que votre instance actuelle (utilisez une AMI similaire ou la même AMI que vous avez utilisée pour votre instance actuelle) et attachez le volume racine à l'instance temporaire. 1. Connectez-vous à l'instance temporaire, créez un point de montage et montez le volume que vous avez joint. 1. A partir de l'instance temporaire, vérifiez les autorisations du répertoire `/home/instance-user-name/` du volume attaché. Si nécessaire, modifiez les autorisations comme suit : ``` [ec2-user ~]$ chmod 600 mount_point/home/instance-user-name/.ssh/authorized_keys ``` ``` [ec2-user ~]$ chmod 700 mount_point/home/instance-user-name/.ssh ``` ``` [ec2-user ~]$ chmod 700 mount_point/home/instance-user-name ``` 1. Démontez le volume, détachez-le de l'instance temporaire et attachez-le de nouveau à l'instance originale. Assurez-vous que vous avez spécifié le bon nom de périphérique pour le volume racine, par exemple, `/dev/xvda`. 1. Démarrez votre instance. Si vous n'avez plus besoin de l'instance temporaire, vous pouvez la mettre en service. ## Erreur : fichier de clé privée non protégé Votre fichier de clé privée doit être protégé des opérations de lecture et d'écriture des autres utilisateurs. Si n'importe qui sauf vous peut lire ou écrire sur votre clé privée, alors SSH ignore votre clé et vous voyez le message d'avertissement suivant. ``` @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0777 for '.ssh/my_private_key.pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: .ssh/my_private_key.pem Permission denied (publickey). ``` Si vous voyez un message similaire lorsque vous essayez de vous connecter à votre instance, examinez la première ligne du message d'erreur pour vérifier que vous utilisez la bonne clé publique pour votre instance. L'exemple ci-dessus utilise la clé privée `.ssh/my_private_key.pem` avec les autorisations sur les fichiers de `0777` ce qui permet à n'importe qui de lire ou écrire sur ce fichier. Ce niveau d'autorisation n'est pas sûr du tout, donc SSH ignore cette clé. Si vous vous connectez à partir de macOs ou Linux, exécutez la commande suivante pour corriger cette erreur en remplaçant le chemin par celui de votre fichier de clé privée. ``` [ec2-user ~]$ chmod 0400 .ssh/my_private_key.pem ``` Si vous vous connectez à une instance Linux à partir de Windows, effectuez les étapes suivantes sur votre ordinateur local. 1. Accédez au fichier .pem. 1. Cliquez avec le bouton droit de la souris sur le fichier .pem et sélectionnez**Propriétés**. 1. Choisissez l'onglet **Security (Sécurité)**. 1. Sélectionnez **Avancé**. 1. Vérifiez que vous êtes le propriétaire du fichier. Si ce n'est pas le cas, changez le propriétaire avec votre nom d'utilisateur. 1. Sélectionnez **Désactiver l'héritage** et **Supprimer toutes les autorisations héritées de cet objet**. 1. Sélectionnez **Ajouter**, **Sélectionnez un principal**, saisissez votre nom d'utilisateur et sélectionnez **OK**. 1. À partir de la fenêtre **Entrée d'autorisation**, attribuez les autorisations **Lire** et sélectionnez **OK**. 1. Cliquez sur **Apply** (Appliquer) afin de garantir l'enregistrement de tous les paramètres. 1. Sélectionnez **OK** pour fermer la fenêtre **Paramètres de sécurité avancés**. 1. Sélectionnez **OK** pour fermer la fenêtre **Propriétés**. 1. Vous devriez être en mesure de vous connecter à votre instance Linux à partir de Windows via SSH. À partir d'une invite de commande Windows, exécutez la commande suivante. 1. À partir de l'invite de commande, accédez à l'emplacement du chemin de fichier de votre fichier .pem. 1. Exécutez la commande suivante pour réinitialiser et supprimer les autorisations explicites : ``` icacls.exe $path /reset ``` 1. Exécutez la commande suivante pour accorder à l'utilisateur actuel les autorisations de lecture : ``` icacls.exe $path /GRANT:R "$($env:USERNAME):(R)" ``` 1. Exécutez la commande suivante pour désactiver l'héritage et supprimer les autorisations héritées. ``` icacls.exe $path /inheritance:r ``` 1. Vous devriez être en mesure de vous connecter à votre instance Linux à partir de Windows via SSH. ## Erreur : La clé privée doit commencer par « -----BEGIN RSA PRIVATE KEY----- » et se terminer par « -----END RSA PRIVATE KEY----- » Si vous utilisez un outil tiers, tel que **ssh-keygen**, pour créer une paire de clés RSA, il génère la clé privée au format de clé OpenSSH. Lorsque vous vous connectez à votre instance, si vous utilisez la clé privée au format OpenSSH pour déchiffrer le mot de passe, vous obtenez l'erreur `Private key must begin with "-----BEGIN RSA PRIVATE KEY-----" and end with "-----END RSA PRIVATE KEY-----"`. Pour résoudre cette erreur, la clé privée doit être au format PEM. Utilisez la commande suivante pour créer la clé privée au format PEM : ``` ssh-keygen -m PEM ``` ## Erreur : échec de la vérification de la clé d’hôte Cette erreur se produit en cas de discordance entre la clé d’hôte stockée sur l’instance dans le fichier `known_hosts` et sur le client. Par exemple, une incompatibilité peut se produire si vous vous connectez à une instance à l’aide d’une adresse IP publique, puis que vous essayez de vous y reconnecter en utilisant une adresse IP publique différente. Cela peut se produire une fois que vous avez ajouté ou supprimé une adresse IP Elastic, car cela modifie l’adresse IP publique d’une instance. Pour résoudre cette erreur, commencez par confirmer qu’une modification de la clé d’hôte ou de la configuration réseau de l’instance est attendue. Avant de vous connecter à l’instance, vous pouvez également [vérifier l’empreinte de l’hôte](connection-prereqs-general.md#connection-prereqs-fingerprint). Une fois connecté à l’instance, vous pouvez supprimer l’ancienne clé d’hôte du fichier `known_hosts`. Pour obtenir des instructions, reportez-vous à la documentation de la distribution Linux utilisée sur votre instance. ## Erreur : le serveur a refusé notre clé *ou* Aucune méthode d'authentification prise en charge disponible Si vous utilisez PuTTY pour vous connecter à votre instance et que vous obtenez l'une des erreurs suivantes, Erreur : Le serveur a refusé votre clé ou Erreur : Méthodes d'authentification disponibles non prises en charge, vérifiez que vous vous connectez avec le nom d'utilisateur approprié pour votre AMI. Saisissez le nom d'utilisateur dans **Nom d'utilisateur** de la fenêtre **Configuration de PuTTY**. Les noms d'utilisateur appropriés sont les suivants : | AMI utilisée pour lancer l’instance | Nom d’utilisateur par défaut | | --- | --- | | Amazon Linux | ec2-user | | CentOS | centos ou ec2-user | | Debian | admin | | Fedora | fedora ou ec2-user | | FreeBSD | ec2-user | | RHEL | ec2-user ou root | | SUSE | ec2-user ou root | | Ubuntu | ubuntu | | Oracle | ec2-user | | Bitnami | bitnami | | Rocky Linux | rocky | | Autre | Vérifiez auprès du fournisseur de l'AMI | Vous devez également vérifier que : + Utilisez-vous la dernière version de PuTTY. Pour plus d'informations, consultez la [page Web PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/). + Votre fichier de clé privée (.pem) a été bien converti au format reconnu par PuTTY (.ppk). Pour plus d'informations sur la conversion de votre clé privée, consultez [Connectez-vous à votre instance Linux à l’aide de PuTTY](connect-linux-inst-from-windows.md). ## Impossible d'envoyer une commande ping à l'instance La commande `ping` est un type de trafic ICMP. Si vous ne pouvez pas pinger votre instance, assurez-vous que vos règles entrantes de groupe de sécurité autorisent le trafic ICMP pour le message `Echo Request` de toutes les sources, ou de l'ordinateur ou de l'instance à partir desquels vous émettez la commande. Si vous ne pouvez pas fournir une commande `ping` à partir de votre instance, assurez-vous que vos règles sortantes de groupe de sécurité autorisent le trafic ICMP pour le message `Echo Request` vers toutes les destinations ou vers l'hôte que vous essayez de pinger. Les commandes `Ping` peuvent également être bloquées par un pare-feu ou un délai d'attente en raison de latence réseau ou de problèmes matériels. Vous devez consulter votre réseau local ou votre administrateur système pour obtenir de l'aide sur la résolution des problèmes supplémentaires. ## Erreur : le serveur a fermé la connexion réseau de manière inopinée Si vous vous connectez à votre instance via PuTTY et que vous recevez le message d'erreur « Le serveur a fermé la connexion réseau de manière inopinée », vérifiez que vous avez activé le paramètre keepalive dans la page de Connexion de la Configuration PuTTY, afin d'éviter de vous faire déconnecter. Certains serveurs déconnectent les clients lorsqu'ils n'ont pas reçu de données dans une période de temps spécifiée. Réglez les secondes entre keepalives à 59 secondes. Si vous éprouvez encore des difficultés après avoir activé les keepalives, essayez de désactiver l'algorithme de Nagle dans la page de Connexion de la Configuration PuTTY. ## Erreur : échec de la validation de la clé d'hôte pour EC2 Instance Connect Si vous faites pivoter les clés d'hôte de votre instance, les nouvelles clés d'hôte ne sont pas automatiquement téléchargées dans la base de données de clés d'hôte AWS fiables. Cela provoque l'échec de la validation de clé d'hôte lorsque vous essayez de vous connecter à votre instance à l'aide du client EC2 Instance Connect basé sur le navigateur et vous ne parvenez pas à vous connecter à votre instance. Pour résoudre cette erreur, vous devez exécuter le script `eic_harvest_hostkeys` sur votre instance, qui télécharge votre nouvelle clé d'hôte vers EC2 Instance Connect. Le script se trouve sur `/opt/aws/bin/` sur les instances Amazon Linux 2 et sur `/usr/share/ec2-instance-connect/` sur les instances Ubuntu. ------ #### [ Amazon Linux 2 ] **Pour résoudre l'erreur de validation de clé d'hôte ayant échoué sur une instance Amazon Linux 2** 1. Connectez-vous à votre instance à l'aide de SSH. Vous pouvez vous connecter en utilisant la CLI EC2 Instance Connect ou la paire de clés SSH attribuée à votre instance lors de son lancement, ainsi que le nom d'utilisateur par défaut de l'AMI utilisée pour lancer votre instance. Pour Amazon Linux 2, le nom d’utilisateur par défaut est `ec2-user`. Par exemple, si votre instance a été lancée avec Amazon Linux 2, que le nom DNS public de votre instance est `ec2-a-b-c-d.us-west-2.compute.amazonaws.com` et que la paire de clés est `my_ec2_private_key.pem`, utilisez la commande suivante pour établir une connexion SSH à votre instance : ``` $ ssh -i my_ec2_private_key.pem ec2-user@ec2-a-b-c-d.us-west-2.compute.amazonaws.com ``` Pour plus d’informations sur la connexion à votre instance, consultez [Connexion à votre instance Linux à l’aide d’un client SSH](connect-linux-inst-ssh.md). 1. Accédez au dossier suivant. ``` [ec2-user ~]$ cd /opt/aws/bin/ ``` 1. Exécutez la commande suivante sur votre instance.
 ``` [ec2-user ~]$ ./eic_harvest_hostkeys ``` Notez qu'un appel réussi n'entraîne pas obligatoirement une sortie. Vous pouvez désormais utiliser le client EC2 Instance Connect basé sur le navigateur pour vous connecter à votre instance. ------ #### [ Ubuntu ] **Pour résoudre l'erreur de validation de clé d'hôte ayant échoué sur une instance Ubuntu** 1. Connectez-vous à votre instance à l’aide de SSH. Vous pouvez vous connecter en utilisant la CLI EC2 Instance Connect ou la paire de clés SSH attribuée à votre instance lors de son lancement, ainsi que le nom d'utilisateur par défaut de l'AMI utilisée pour lancer votre instance. Pour Ubuntu, le nom d'utilisateur par défaut est `ubuntu`. Par exemple, si votre instance a été lancée avec Ubuntu, que le nom DNS public de votre instance est `ec2-a-b-c-d.us-west-2.compute.amazonaws.com` et que la paire de clés est `my_ec2_private_key.pem`, utilisez la commande suivante pour établir une connexion SSH à votre instance : ``` $ ssh -i my_ec2_private_key.pem ubuntu@ec2-a-b-c-d.us-west-2.compute.amazonaws.com ``` Pour plus d’informations sur la connexion à votre instance, consultez [Connexion à votre instance Linux à l’aide d’un client SSH](connect-linux-inst-ssh.md). 1. Accédez au dossier suivant. ``` [ec2-user ~]$ cd /usr/share/ec2-instance-connect/ ``` 1. Exécutez la commande suivante sur votre instance.
 ``` [ec2-user ~]$ ./eic_harvest_hostkeys ``` Notez qu'un appel réussi n'entraîne pas obligatoirement une sortie. Vous pouvez désormais utiliser le client EC2 Instance Connect basé sur le navigateur pour vous connecter à votre instance. ------ ## Impossible de se connecter à une instance Ubuntu à l'aide de EC2 Instance Connect Si vous utilisez EC2 Instance Connect pour vous connecter à votre instance Ubuntu et que vous obtenez une erreur lorsque vous tentez de vous connecter, vous pouvez utiliser les informations suivantes pour tenter de résoudre le problème. **Cause possible** Le package `ec2-instance-connect` sur l'instance n'est pas la dernière version. **Solution** Mettre à jour le package `ec2-instance-connect` sur l'instance vers la dernière version, comme suit : 1. [Se connecter](connect-to-linux-instance.md) à votre instance en utilisant une méthode autre que EC2 Instance Connect. 1. Exécuter la commande suivante sur votre instance pour mettre à jour le package `ec2-instance-connect` vers la dernière version. ``` apt update && apt upgrade ``` ## J’ai perdu ma clé privée. Comment puis-je me connecter à mon instance ? Si vous perdez la clé privée pour une instance basée sur des volumes EBS, vous pouvez à nouveau accéder à votre instance. Vous devez arrêter l'instance, détacher son volume racine et l'attacher à une autre instance en tant que volume de données, modifier le fichier `authorized_keys` avec une nouvelle clé publique, replacer le volume dans l'instance d'origine et redémarrer l'instance. Pour plus d'informations sur le lancement et l'arrêt des instances, ainsi que sur la connexion aux instances, consultez [Modifications de l'état de l' EC2 instance Amazon](ec2-instance-lifecycle.md). Cette procédure est prise en charge uniquement pour des instances avec des volumes racine EBS. Si l’instance dispose d’un volume racine de stockage d’instances, vous ne pouvez pas utiliser cette procédure pour retrouver l’accès à votre instance ; vous devez disposer de la clé privée pour vous connecter à l’instance. Pour déterminer le type de volume racine de votre instance, ouvrez la console Amazon EC2, sélectionnez **Instances**, sélectionnez l’instance, choisissez l’onglet **Stockage**, puis dans la section **Détails du périphérique racine**, vérifiez la valeur de **Type de périphérique racine**. La valeur est `EBS` ou `INSTANCE-STORE`. En plus des étapes suivantes, il existe d'autres façons de vous connecter à votre instance Linux en cas de perte de votre clé privée. Pour de plus amples informations, veuillez consulter [Comment puis-je me connecter à mon instance Amazon EC2 si j'ai perdu ma paire de clés SSH après son lancement initial ?](https://repost.aws/knowledge-center/user-data-replace-key-pair-ec2) **Topics** + [Étape 1 : Créer une nouvelle paire de clés](#step-1-create-new-key-pair) + [Étape 2 : Obtenir des informations sur l'instance d'origine et son volume racine](#step-2-get-info-about-original-instance) + [Étape 3 : Arrêter l'instance d'origine](#step-3-stop-original-instance) + [Étape 4 : Lancer une instance temporaire](#step-4-launch-temp-instance) + [Étape 5 : Détacher le volume racine de l'instance d'origine et l'attacher à l'instance temporaire](#step-5-detach-root-volume-and-attach-to-temp-instance) + [Étape 6 : Ajouter la nouvelle clé publique `authorized_keys` sur le volume d'origine monté sur l'instance temporaire](#step-6-add-new-public-key-to-authorized_keys) + [Étape 7 : Démonter et détacher le volume d'origine de l'instance temporaire, puis le reconnecter à l'instance d'origine](#step-7-unmount-detach-volume-and-reattach-to-original-instance) + [Étape 8 : Se connecter à l'instance d'origine à l'aide de la nouvelle paire de clés](#step-8-connect-to-original-instance) + [Étape 9 : nettoyer](#step-9-clean-up) ### Étape 1 : Créer une nouvelle paire de clés Créer une nouvelle paire de clés à l'aide de la console Amazon EC2 ou d'un outil tiers. Si vous souhaitez nommer votre nouvelle paire de clés exactement comme la clé privée perdue, vous devez commencer par supprimer la paire de clés existante. Pour de plus amples informations sur la création d'une paire de clés, veuillez consulter [Créer une paire de clés à l’aide d’Amazon EC2](create-key-pairs.md#having-ec2-create-your-key-pair) ou [Créer une paire de clés à l’aide d’un outil tiers et importer la clé publique dans Amazon EC2](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws). ### Étape 2 : Obtenir des informations sur l'instance d'origine et son volume racine Notez les informations suivantes, car vous en aurez besoin pour effectuer cette procédure. **Pour obtenir des informations sur votre instance d'origine** 1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Choisissez **Instances** dans le panneau de navigation, puis sélectionnez l'instance à laquelle vous souhaitez vous connecter. (Cette instance est qualifiée d'instance *d'origine*.) 1. Sous l'onglet **Details (Détails)**, notez l'ID d'instance et l'ID d'AMI. 1. Sous l'onglet **Networking (Réseaux)**, notez la zone de disponibilité. 1. Sous l'onglet **Storage (Stockage)**, sous **Root device name (Nom du périphérique racine)**, notez le nom du périphérique pour le volume racine (par exemple, `/dev/xvda`). Ensuite, sous **Block devices** (Bloquer les périphériques), recherchez le nom du périphérique et notez l'ID de volume (par exemple, vol-0a1234b5678c910de). ### Étape 3 : Arrêter l'instance d'origine Choisissez **État de l'instance**, **Arrêter l'instance**. Si cette option est désactivée, l’instance est déjà arrêtée ou son volume racine est un volume de stockage d’instances. **Avertissement** Lorsque vous arrêtez une instance, les données relatives aux volumes de stockage de l'instance sont perdues. Pour conserver ces données, sauvegardez-les dans un espace de stockage permanent. ### Étape 4 : Lancer une instance temporaire **Pour lancer une instance temporaire** 1. Dans le volet de navigation, choisissez **Instances**, puis **Launch instances** (Lancer des instances). 1. Dans la section **Name and tags** (Noms et identifications), pour **Name** (Nom), saisissez **Temporary** (Temporaire). 1. Dans **Application and OS Images** (Images d'applications et de systèmes d'exploitation), sélectionnez la même AMI que celle utilisée pour lancer l'instance d'origine. Si l'AMI n'est pas disponible, vous pouvez créer une AMI à utiliser depuis l'instance arrêtée. Pour de plus amples informations, veuillez consulter [Créer une AMI basée sur Amazon EBS](creating-an-ami-ebs.md). 1. Dans la section **Instance type** (Type d'instance), sélectionnez le type d'instance par défaut. 1. Dans la section **Key pair** (Paire de clés), pour **Key pair name** (Nom de la paire de clés), sélectionnez une paire de clés existante ou créez-en une. 1. Dans la section **Network settings** (Paramètres réseau), choisissez **Edit** (Modifier), puis pour **Subnet** (Sous-réseau), sélectionnez un sous-réseau dans la même zone de disponibilité que celle de l'instance d'origine. 1. Dans le panneau **Summary** (Récapitulatif), choisissez **Launch** (Lancer). ### Étape 5 : Détacher le volume racine de l'instance d'origine et l'attacher à l'instance temporaire 1. Dans le panneau de navigation, sélectionnez **Volumes**, puis le volume racine pour l’instance d’origine (vous avez noté l’ID de volume au cours d’une étape précédente). Choisissez **Actions**, **Detach Volume** (Détacher un volume), puis choisissez **Detach** (Détacher). Attendez que l'état du volume devienne `available`. (Vous devrez peut-être sélectionner l'icône **Actualiser**.) 1. Tandis que le volume est toujours sélectionné, choisissez **Actions**, puis choisissez **Attach volume** (Attacher un volume). Sélectionnez l'ID d'instance de l'instance temporaire, notez le nom du périphérique spécifié dans **Device name** (Nom du périphérique) (par exemple, `/dev/sdf`), puis sélectionnez **Attach volume** (Attacher un volume). **Note** Si vous avez lancé votre instance d'origine depuis une AWS Marketplace AMI et que votre volume contient des AWS Marketplace codes, vous devez d'abord arrêter l'instance temporaire avant de pouvoir attacher le volume. ### Étape 6 : Ajouter la nouvelle clé publique `authorized_keys` sur le volume d'origine monté sur l'instance temporaire 1. Connectez-vous à l'instance temporaire. 1. À partir de l'instance temporaire, montez le volume que vous avez attaché à l'instance afin de pouvoir accéder au système de fichiers. Par exemple, si le nom du périphérique est `/dev/sdf`, utilisez les commandes suivantes pour monter le volume en tant que `/mnt/tempvol`. **Note** Le nom du périphérique peut apparaître différemment sur votre instance. Par exemple, les périphériques montés en tant que `/dev/sdf` peuvent également s'afficher en tant que `/dev/xvdf` sur l'instance. Certaines versions de Red Hat (ou ses variantes, comme CentOS) peuvent même incrémenter la lettre finale de quatre caractères, et `/dev/sdf` devient `/dev/xvdk`. 1. Utilisez la commande **lsblk** pour déterminer si le volume est divisé. ``` [ec2-user ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk └─xvda1 202:1 0 8G 0 part / xvdf 202:80 0 101G 0 disk └─xvdf1 202:81 0 101G 0 part xvdg 202:96 0 30G 0 disk ``` Dans l'exemple précédent, `/dev/xvda` et `/dev/xvdf` sont des volumes partitionnés, mais `/dev/xvdg` ne l'est pas. Si votre volume est partitionné, vous montez la partition (`/dev/xvdf1)`) au lieu du périphérique brut (`/dev/xvdf`) au cours des étapes suivantes. 1. Créez un répertoire temporaire pour monter le volume. ``` [ec2-user ~]$ sudo mkdir /mnt/tempvol ``` 1. Montez le volume (ou la partition) sur le point de montage temporaire, en utilisant le nom du volume ou du périphérique que vous avez identifié plus tôt. La commande requise dépend du système de fichiers de votre système d'exploitation. Notez que le nom du périphérique peut apparaître différemment sur votre instance. Reportez-vous à l'étape 6 de [note](#device-name) pour plus d'informations. + Amazon Linux, Ubuntu et Debian ``` [ec2-user ~]$ sudo mount /dev/xvdf1 /mnt/tempvol ``` + Amazon Linux 2, CentOS, SUSE Linux 12 et RHEL 7.x ``` [ec2-user ~]$ sudo mount -o nouuid /dev/xvdf1 /mnt/tempvol ``` **Note** Si vous obtenez une erreur indiquant que le système de fichiers est endommagé, exécutez la commande suivante pour utiliser l'utilitaire **fsck** afin de rechercher les erreurs dans votre système de fichiers et de les résoudre. ``` [ec2-user ~]$ sudo fsck /dev/xvdf1 ``` 1. À partir de l'instance temporaire, utilisez la commande suivante pour mettre à jour `authorized_keys` sur le volume monté avec la nouvelle clé publique de `authorized_keys` pour l'instance temporaire. **Important** Les exemples suivants utilisent le nom d'utilisateur Amazon Linux `ec2-user`. Vous devrez peut-être modifier le nom d'utilisateur, par exemple, `ubuntu` pour les instances Ubuntu. ``` [ec2-user ~]$ cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys ``` Une fois que cette étape est correctement effectuée, vous pouvez passer à l'étape suivante. (Facultatif) Sinon, si vous n'êtes pas autorisé à modifier des fichiers dans `/mnt/tempvol`, vous devez mettre à jour le fichier à l'aide de la commande **sudo**, puis vérifier les autorisations sur le fichier afin de vous assurer que vous êtes en mesure de vous connecter à l'instance d'origine. Pour vérifier les autorisations sur le fichier, utilisez la commande suivante. ``` [ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh total 4 -rw------- 1 222 500 398 Sep 13 22:54 authorized_keys ``` Dans cet exemple de sortie, *222* il s'agit de l'ID utilisateur et *500* de l'ID du groupe. Utilisez ensuite la commande **sudo** pour ré-exécuter la commande copy ayant échoué. ``` [ec2-user ~]$ sudo cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys ``` Exécutez à nouveau la commande suivante pour déterminer si les autorisations ont été modifiées. ``` [ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh ``` Si l'ID d'utilisateur et l'ID de groupe ont été modifiés, utilisez la commande suivante pour les restaurer. ``` [ec2-user ~]$ sudo chown 222:500 /mnt/tempvol/home/ec2-user/.ssh/authorized_keys ``` ### Étape 7 : Démonter et détacher le volume d'origine de l'instance temporaire, puis le reconnecter à l'instance d'origine 1. À partir de l'instance temporaire, démontez le volume que vous avez attaché afin de pouvoir l'attacher à nouveau à l'instance d'origine. Par exemple, utilisez la commande suivante pour démonter le volume situé dans `/mnt/tempvol`. ``` [ec2-user ~]$ sudo umount /mnt/tempvol ``` 1. Détachez le volume de l’instance temporaire (vous l’avez démonté à l’étape précédente) : dans la console Amazon EC2, choisissez **Volumes** dans le panneau de navigation, sélectionnez le volume racine de l’instance d’origine (vous avez noté l’ID de volume à l’étape précédente), choisissez **Actions**, **Détacher un volume**, puis **Détacher**. Attendez que l'état du volume devienne `available`. (Vous devrez peut-être sélectionner l'icône **Actualiser**.) 1. Rattachez le volume à l'instance d'origine : le volume étant toujours sélectionné, choisissez **Actions**, **Attach volume** (Attacher un volume). Sélectionnez l’ID d’instance de l’instance d’origine, précisez le nom du périphérique que vous avez noté précédemment au cours de l’[étape 2](#step-2-get-info-about-original-instance) pour l’attachement du volume racine d’origine (`/dev/sda1` ou `/dev/xvda`), puis choisissez **Attacher un volume**. **Important** Si vous ne spécifiez pas le même nom de périphérique que pour l'attachement original, vous ne pourrez pas démarrer l'instance d'origine. Amazon EC2 s’attend à ce que le volume racine soit sur `sda1` ou `/dev/xvda`. ### Étape 8 : Se connecter à l'instance d'origine à l'aide de la nouvelle paire de clés Sélectionnez l'instance d'origine, choisissez **État de l'instance**, **Démarrer l'instance**. Lorsque l'état de l'instance est `running`, vous pouvez vous y connecter à l'aide du fichier de clé privée de votre nouvelle paire de clés. **Note** Si le nom de votre paire de clés et du fichier de clé privée correspondant est différent du nom de la paire de clés initiale, veillez à spécifier le nom du nouveau fichier de clé privée lorsque vous vous connectez à votre instance. ### Étape 9 : nettoyer (Facultatif) Vous pouvez mettre fin à l'instance temporaire si vous n'en avez plus besoin. Sélectionnez l'instance temporaire, puis **Instance State** (État de l'instance) et **Terminate instance** (Résilier l'instance).