Résoudre les problèmes de connexion à votre instance Linux - Amazon Elastic Compute Cloud

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 Linux

Les informations suivantes et les erreurs courantes peuvent vous aider à résoudre les problèmes de connexion à votre instance Linux.

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 Linux.

  • Obtenir le nom d’utilisateur par défaut pour l’AMI que vous avez utilisée pour lancer votre instance :

    AMI utilisée pour lancer l’instance Nom d’utilisateur par défaut

    AL2023

    Amazon Linux 2

    Amazon Linux

    ec2-user
    CentOS centos ou ec2-user
    Debian admin
    Fedora fedora ou 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
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. Pour connaître les étapes à vérifier, consultez Erreur de connexion à votre instance : connexion expirée.

Vérifiez que votre instance est prête

Une fois l'instance lancée, il peut falloir quelques minutes pour qu'elle soit prête pour que vous puissiez vous y connecter. 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 sur https://console.aws.amazon.com/ec2/.

  2. Dans le panneau de navigation, choisissez instances, puis sélectionnez votre instance.

  3. Vérifiez les paramètres suivants :

    1. Dans la colonne État de l'instance, vérifiez que l'état de votre instance est running.

    2. Dans la colonne Contrôle des statuts, vérifiez que votre instance a passé avec succès les deux vérifications 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 plus d’informations, consultez Connectez-vous à votre instance Linux.

Pour connaître les prérequis spécifiques aux types de connexion, tels que SSH, EC2 Instance Connect, OpenSSH, PuTTY, etc., consultez les options suivantes.

Linux ou macOS X

Si le système d'exploitation de votre ordinateur local est Linux ou macOS X, vérifiez les prérequis spécifiques pour les options de connexion suivantes :

Windows

Si le système d'exploitation de votre ordinateur local est Windows, vérifiez les prérequis spécifiques pour les options de connexion suivantes :

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'un groupe de sécurité qui permet le trafic entrant à partir de votre adresse IPv4 publique de votre ordinateur local sur le même port.

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

  2. Dans le panneau de navigation, choisissez instances, puis sélectionnez votre instance.

  3. 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.

    • Pour les instances Linux : vérifiez qu'il existe une règle qui permet le trafic de votre ordinateur local au port 22 (SSH).

    • Pour les instances Windows : vérifiez qu'il existe une règle qui permet le trafic de votre ordinateur local au port 3389 (RDP).

    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 plus d’informations, consultez Règles pour la connexion à des instances à partir de votre ordinateur.

  4. Pour connaître la règle qui autorise le trafic entrant, consultez laSource. 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 pourSource, 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é 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 sur https://console.aws.amazon.com/ec2/.

  2. Dans le panneau de navigation, choisissez instances, puis sélectionnez votre instance.

  3. Sous l'onglet Mise en réseau, notez les valeurs de l'ID VPC et de l'ID de sous-réseau.

  4. Ouvrez la console Amazon VPC sur https://console.aws.amazon.com/vpc/.

  5. 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.

  6. Dans le panneau de navigation, sélectionnez Sous-réseaux, puis sélectionnez votre sous-réseau.

  7. 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 adresse IPv6, vérifiez qu'il existe une route pour tout le trafic IPv6 (::/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.

    2. 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 Add route (Ajouter une route) et utilisez ::/0 comme destination et la passerelle Internet comme cible.

    3. 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.

Les listes ACL de réseau doivent autoriser le trafic entrant à partir de votre adresse IP locale sur le port 22 (pour les instances Linux) ou le port 3389 (pour les instances Windows). 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/.

  2. Dans le volet de navigation, choisissez Subnets.

  3. Sélectionnez votre sous-réseau.

  4. 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.

  5. 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 de réseau si le pare-feu interne permet le trafic entrant et sortant à partir de votre ordinateur sur le port 22 (pour les instances Linux) ou le port 3389 (pour les instances Windows).

Si vous avez un pare-feu sur votre ordinateur, vérifiez s'il permet le trafic entrant et sortant à partir de votre ordinateur sur le port 22 (pour les instances Linux) ou le port 3389 (pour les instances Windows).

Vérifiez que votre instance possède une adresse IPv4 publique.

Si non, vous pouvez associer une adresse IP Elastic à votre instance. Pour plus d’informations, consultez Adresses IP Elastic.

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 plus d’informations, consultez Surveillez vos instances à l'aide de CloudWatch.

  • Si votre charge est variable, vous pouvez automatiquement effectuer des mises à l'échelle ascendantes et descendantes de vos instances en utilisant l'Auto Scaling et l'Elastic Load Balancing.

  • Si votre charge augmente régulièrement, vous pouvez passer à un type d'instance plus important. Pour plus d’informations, consultez Modifier le type d'instance.

Pour vous connecter à votre instance à l'aide d'une adresse IPv6, vérifiez les points suivants :

  • Votre sous-réseau doit être associé à une table de routage ayant une route pour le trafic IPv6 (::/0) vers une passerelle Internet.

  • Vos règles de groupe de sécurité doivent autoriser le trafic entrant à partir de votre adresse IPv6 locale sur le port approprié (22 pour Linux et 3389 pour Windows).

  • Vos règles ACL réseau doivent autoriser le trafic IPv6 entrant et sortant.

  • Si vous avez lancé votre instance à partir d'une AMI plus ancienne, elle n'est peut-être pas configurée pour DHCPv6 (les adresses IPv6 ne sont pas automatiquement reconnues sur l'interface réseau). Pour plus d’informations, consultez Configuration d’IPv6 sur vos instances dans le Guide de l’utilisateur Amazon VPC.

  • Votre ordinateur local doit avoir une adresse IPv6 et doit être configuré pour utiliser 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 plus d’informations, consultez Créer une paire de clés à l’aide d’Amazon EC2.

    Note

    Sinon, vous pouvez créer une nouvelle key pair à l'aide d'un outil tiers. Pour plus d’informations, consultez Créer une paire de clés à l’aide d’un outil tiers et importer la clé publique dans Amazon EC2.

  2. Ajoutez la nouvelle paire de clés à votre instance. Pour plus d’informations, consultez J'ai perdu ma clé privée. Comment puis-je me connecter à mon instance Linux ?.

  3. 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 Connexion à votre instance Linux à partir de Windows à l’aide de PuTTY.

    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 utilisateur approprié pour votre AMI. Saisissez le nom d'utilisateur dans le champ Nom d'hôte de la fenêtre Configuration de PuTTY.

    AMI utilisée pour lancer l'instance Nom d’utilisateur par défaut

    AL2023

    Amazon Linux 2

    Amazon Linux

    ec2-user
    CentOS centos ou ec2-user
    Debian admin
    Fedora fedora ou 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
  • Vérifiez que vous avez une règle entrante de groupe de sécurité pour permettre le trafic entrant vers le port approprié. Pour plus d’informations, consultez Règles pour la connexion à des instances à partir de votre ordinateur.

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 comme suit :

AMI utilisée pour lancer l'instance Nom d’utilisateur par défaut

AL2023

Amazon Linux 2

Amazon Linux

ec2-user
CentOS centos ou ec2-user
Debian admin
Fedora fedora ou 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 sur https://console.aws.amazon.com/ec2/.

  2. Dans le panneau de navigation, choisissez Instances, puis sélectionnez votre instance.

  3. Sous l'onglet Détails, sous Détails de l'instance, vérifiez la valeur Nom de la paire de clés.

  4. 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 plus d’informations, consultez J'ai perdu ma clé privée. Comment puis-je me connecter à mon instance Linux ?.

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 plus d’informations, consultez Arrêtez et démarrez les instances Amazon EC2.

  2. 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.

  3. Connectez-vous à l'instance temporaire, créez un point de montage et montez le volume que vous avez joint.

  4. 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
  5. 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.

  6. 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 à partir de Windows, exécutez les étapes suivantes sur votre ordinateur local.

  1. Accédez au fichier .pem.

  2. Cliquez avec le bouton droit de la souris sur le fichier .pem et sélectionnezPropriétés.

  3. Choisissez l'onglet Security (Sécurité).

  4. Sélectionnez Avancé.

  5. 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.

  6. Sélectionnez Désactiver l'héritage et Supprimer toutes les autorisations héritées de cet objet.

  7. Sélectionnez Ajouter, Sélectionnez un principal, saisissez votre nom d'utilisateur et sélectionnez OK.

  8. À partir de la fenêtre Entrée d'autorisation, attribuez les autorisations Lire et sélectionnez OK.

  9. Cliquez sur Apply (Appliquer) afin de garantir l'enregistrement de tous les paramètres.

  10. Sélectionnez OK pour fermer la fenêtre Paramètres de sécurité avancés.

  11. Sélectionnez OK pour fermer la fenêtre Propriétés.

  12. 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.

  2. Exécutez la commande suivante pour réinitialiser et supprimer les autorisations explicites :

    icacls.exe $path /reset
  3. Exécutez la commande suivante pour accorder à l'utilisateur actuel les autorisations de lecture :

    icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
  4. Exécutez la commande suivante pour désactiver l'héritage et supprimer les autorisations héritées.

    icacls.exe $path /inheritance:r
  5. 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 : 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. Entrez le nom d'utilisateur dans le champ Nom d'utilisateur de la fenêtre Configuration de PuTTY.

Les noms d'utilisateur appropriés sont comme suit :

AMI utilisée pour lancer l'instance Nom d’utilisateur par défaut

AL2023

Amazon Linux 2

Amazon Linux

ec2-user
CentOS centos ou ec2-user
Debian admin
Fedora fedora ou 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 :

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 depuis Linux ou macOS à l’aide de SSH.

  2. Accédez au dossier suivant.

    [ec2-user ~]$ cd /opt/aws/bin/
  3. 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 depuis Linux ou macOS à l’aide de SSH.

  2. Accédez au dossier suivant.

    [ec2-user ~]$ cd /usr/share/ec2-instance-connect/
  3. 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 à votre instance en utilisant une méthode autre que EC2 Instance Connect.

  2. 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 Linux ?

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 Cycle de vie d’une instance.

Cette procédure est prise en charge uniquement pour des instances avec des volumes racine EBS. Si l'appareil racine est un volume de stockage d'instance, vous ne pouvez pas utiliser cette procédure pour rétablir l'accès à votre instance ; vous devez disposer de la clé privée pour vous connecter à l'instance. Pour déterminer le type d'appareil racine de votre instance, ouvrez la console Amazon EC2, choisissez Instances, sélectionnez l'instance, choisissez l'onglet Stockage, et dans la section Détails de l'appareil racine, vérifiez la valeur du Type d'appareil 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 ?

É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 ou Créer une paire de clés à l’aide d’un outil tiers et importer la clé publique dans Amazon EC2.

É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/.

  2. 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.)

  3. Sous l'onglet Details (Détails), notez l'ID d'instance et l'ID d'AMI.

  4. Sous l'onglet Networking (Réseaux), notez la zone de disponibilité.

  5. 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 périphérique racine est un volume de stockage d'instance.

Avertissement

Lorsque vous arrêtez une instance, les données contenues sur les volumes de stockage d'instance sont effacées. Pour conserver les données provenant des volumes de stockage d'instances, sauvegardez-les sur un stockage permanent.

Étape 4 : Lancer une instance temporaire

New console
Pour lancer une instance temporaire
  1. Dans le volet de navigation, choisissez Instances, puis Launch instances (Lancer des instances).

  2. Dans la section Name and tags (Noms et identifications), pour Name (Nom), saisissez Temporary (Temporaire).

  3. 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 plus d’informations, consultez Création d'une AMI basée sur Amazon EBS.

  4. Dans la section Instance type (Type d'instance), sélectionnez le type d'instance par défaut.

  5. 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.

  6. 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.

  7. Dans le panneau Summary (Récapitulatif), choisissez Launch (Lancer).

Old console

Sélectionnez Launch instances (Lancer des instances), puis utilisez l'assistant de lancement pour lancer une instance temporaire avec les options suivantes :

  • Dans la page Choisir une AMI, 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 plus d’informations, consultez Création d'une AMI basée sur Amazon EBS.

  • Sur la page Choisir un type d'instance, conservez le type d'instance par défaut sélectionné par l'assistant.

  • Dans la page Configurer les détails de l'instance, spécifiez la même zone de disponibilité que l'instance d'origine. Si vous lancez une instance dans un VPC, sélectionnez un sous-réseau dans cette zone de disponibilité.

  • Sur la page Ajouter des balises, ajoutez la balise Name=Temporary à l'instance pour indiquer qu'il s'agit d'une instance temporaire.

  • Sur la page Review (Vérification), choisissez Launch (Lancer). Sélectionnez la paire de clés que vous avez créée à l'étape 1, puis sélectionnez Launch instances (Lancer les instances).

É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 du périphérique 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.)

  2. 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 à partir d'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.

  2. À 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.

    2. Créez un répertoire temporaire pour monter le volume.

      [ec2-user ~]$ sudo mkdir /mnt/tempvol
    3. 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 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
  3. À 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, 222 est l'ID d'utilisateur et 500 est l'ID de 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
  2. 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 du périphérique racine de l'instance d'origine (vous avez noté l'ID de volume à l'étape précédente), sélectionnez Actions, Detach volume (Détacher un volume), puis Detach (Détacher). Attendez que l'état du volume devienne available. (Vous devrez peut-être sélectionner l'icône Actualiser.)

  3. 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 de l'appareil que vous avez noté précédemment au cours de l'étape 2 pour l'attachement de l'appareil racine d'origine (/dev/sda1 ou /dev/xvda), puis choisissez Attach volume (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 du périphérique racine soit 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).