Amazon Elastic Compute Cloud
Guide de l'utilisateur pour les instances Linux

Résolution de la connexion à votre instance

Vous trouverez ci-dessous des problèmes possibles que vous rencontrez peut-être et des messages d'erreur que vous pouvez voir lorsque vous essayez de vous connecter à votre instance.

Pour plus d'informations sur les instances Windows, consultez Résolution des problèmes liés aux instances Windows dans le Amazon EC2 Guide de l'utilisateur pour les instances Windows.

Erreur de connexion à votre instance : connexion expirée

Si vous essayez de vous connecter à votre instance et vous obtenez un 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 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. Dans l'onglet Description en bas de la page de la console, en regard de Groupes de sécurité, sélectionnez afficher les règles pour afficher la liste des règles en vigueur pour l'instance sélectionnée.

    4. Pour les instances Linux : lorsque vous sélectionnez afficher les règles, une fenêtre contenant les ports sur lesquels le trafic est autorisé s'affiche. Vérifiez qu'il existe une règle qui autorise le trafic de votre ordinateur au port 22 (SSH).

      Pour les instances Windows : lorsque vous sélectionnez afficher les règles, une fenêtre contenant les ports sur lesquels le trafic est autorisé s'affiche. Vérifiez qu'il existe une règle qui autorise le trafic de votre ordinateur au port 3389 (RDP).

      Chaque fois que vous redémarrez une instance, une nouvelle adresse IP (ainsi qu'un nom d'hôte) lui est affectée. Si votre groupe de sécurité possède une règle qui permet le trafic entrant à partir d'une seule adresse IP, il se peut que cette adresse ne soit pas statique si votre ordinateur est sur un réseau d'entreprise ou si vous vous connectez via un fournisseur de services Internet (ISP). Au lieu de cela, spécifiez la plage d'adresses IP utilisées par les ordinateurs clients. Si votre groupe de sécurité ne possède pas de règle qui permet le trafic entrant comme ce qui est décrit dans l'étape précédente, ajoutez une règle à votre règle de sécurité. Pour plus d'informations, consultez Autorisation de l'accès réseau à vos instances.

      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 d'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/.

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

    3. Dans l'onglet Description, écrivez les valeurs de ID de VPC et ID de sous-réseau.

    4. Ouvrez la console Amazon VPC à l'adresse 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 pour créer une passerelle Internet. Sélectionnez la passerelle Internet, puis choisissez Attacher au VPC et suivez les instructions 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. L'ACL réseau doit permettre le trafic entrant et sortant à partir de votre adresse IP locale sur le même port. L'ACL réseau par défaut permet tout le trafic entrant et sortant.

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

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

    3. Dans l'onglet Description, recherchez ACL réseau et choisissez son ID (acl-xxxxxxxx).

    4. Sélectionnez l'ACL réseau. Pour Règles entrantes, vérifiez que les règles autorisent le trafic à partir de votre ordinateur. Sinon, supprimez ou modifiez la règle qui bloque le trafic à partir de votre ordinateur.

    5. Pour Règles sortantes, vérifiez que les règles autorisent le trafic vers votre ordinateur. Sinon, supprimez ou modifiez la règle qui bloque le trafic vers votre ordinateur.

  • Si votre ordinateur est 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, comme les métriques Amazon CloudWatch et le statut des instances, que vous pouvez utiliser pour voir quelle charge de l'UC se trouve sur votre instance et, si nécessaire, pour ajuster la gestion de vos charges. Pour plus d'informations, consultez Surveillance de vos instances avec 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 Modification du 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 Amazon VPC Guide de l'utilisateur.

  • Votre ordinateur local doit avoir une adresse IPv6 et doit être configuré pour utiliser IPv6.

Erreur : unable to load key… Expecting: ANY PRIVATE KEY

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éation d'une paire de clés à l'aide d'Amazon EC2.

  2. Ajoutez la nouvelle paire de clés à votre instance. Pour plus d'informations, consultez Connexion à votre instance Linux en cas de perte de votre clé privée.

  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 [your key name].pem ec2-user@[public DNS address of your instance].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 Save Private Key (Enregistrer la clé privée) plutôt que Generate (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 Host name (Nom d'hôte) de la fenêtre PuTTY Configuration (Configuration de PuTTY).

    • Pour Amazon Linux 2 ou l'AMI Amazon Linux, le nom d'utilisateur est ec2-user.

    • Pour une AMI CentOS, le nom d'utilisateur est centos.

    • Pour une AMI Debian, le nom d'utilisateur est admin ou root.

    • Pour une AMI Fedora, le nom d'utilisateur est ec2-user ou fedora.

    • Pour une AMI RHEL, le nom d'utilisateur est ec2-user ou root.

    • Pour une AMI SUSE, le nom d'utilisateur est ec2-user ou root.

    • Pour une AMI Ubuntu, le nom utilisateur est ubuntu.

    • Si ec2-user et root ne fonctionnent pas, renseignez-vous auprès de votre fournisseur 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 Autorisation de l'accès réseau à vos instances.

Erreur : clé d'hôte non trouvée, autorisation refusée (publickey), ou échec de l'authentification, autorisation refusée

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) ou Authentication failed, permission denied, vérifiez que vous vous connectez avec nom d'utilisateur approprié pour votre AMI et que vous avez indiqué le bon fichier de clé privée (.pem)) pour votre instance.

Les noms utilisateur appropriés sont comme suit :

  • Pour Amazon Linux 2 ou l'AMI Amazon Linux, le nom d'utilisateur est ec2-user.

  • Pour une AMI CentOS, le nom d'utilisateur est centos.

  • Pour une AMI Debian, le nom d'utilisateur est admin ou root.

  • Pour une AMI Fedora, le nom d'utilisateur est ec2-user ou fedora.

  • Pour une AMI RHEL, le nom d'utilisateur est ec2-user ou root.

  • Pour une AMI SUSE, le nom d'utilisateur est ec2-user ou root.

  • Pour une AMI Ubuntu, le nom utilisateur est ubuntu.

  • Si ec2-user et root ne fonctionnent pas, renseignez-vous auprès de votre fournisseur AMI.

Pa exemple, pour utiliser un client SSH et vous connecter à une instance Amazon Linux, utilisez la commande suivante :

ssh -i /path/my-key-pair.pem ec2-user@public-dns-hostname

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

  2. Sélectionnez votre instance. Dans l'onglet Description, vérifiez la valeur de Nom de la paire de clés.

  3. 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 Connexion à votre instance Linux en cas de perte de votre clé privée.

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/ec2-user/.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êt et démarrage de votre instance et Détacher un volume Amazon EBS d'une instance.

  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. Pour plus d'informations, consultez Attacher un volume Amazon EBS à une instance.

  3. Connectez-vous à l'instance temporaire, créez un point de montage et montez le volume que vous avez joint. Pour plus d'informations, consultez Rendre un volume Amazon EBS disponible à l'utilisation sur le Linux.

  4. A partir de l'instance temporaire, vérifiez les autorisations du répertoire /home/ec2-user/ du volume attaché. Si nécessaire, modifiez les autorisations comme suit :

    [ec2-user ~]$ chmod 600 mount_point/home/ec2-user/.ssh/authorized_keys
    [ec2-user ~]$ chmod 700 mount_point/home/ec2-user/.ssh
    [ec2-user ~]$ chmod 700 mount_point/home/ec2-user
  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 utiliser 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é. Pour corriger cette erreur, exécutez la commande suivante en remplaçant le chemin de votre fichier de clé privée.

[ec2-user ~]$ chmod 0400 .ssh/my_private_key.pem

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 PuTTY Configuration (Configuration de PuTTY).

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

  • Pour Amazon Linux 2 ou l'AMI Amazon Linux, le nom d'utilisateur est ec2-user.

  • Pour une AMI CentOS, le nom d'utilisateur est centos.

  • Pour une AMI Debian, le nom d'utilisateur est admin ou root.

  • Pour une AMI Fedora, le nom d'utilisateur est ec2-user ou fedora.

  • Pour une AMI RHEL, le nom d'utilisateur est ec2-user ou root.

  • Pour une AMI SUSE, le nom d'utilisateur est ec2-user ou root.

  • Pour une AMI Ubuntu, le nom utilisateur est ubuntu.

  • Si ec2-user et root ne fonctionnent pas, renseignez-vous auprès de votre fournisseur AMI.

Vous devriez aussi vérifier que votre fichier de clé privée (.pem) a été correctement 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.

Impossible de me connecter à l'aide de mon navigateur

La console Amazon EC2 fournit une option vous permettant de vous connecter à vos instances directement à partir de votre navigateur à l'aide d'un client SSH Java. Si votre navigateur ne prend pas en charge NPAPI, vous recevez un message d'erreur Dépréciation de NPAPI sur Chrome lorsque vous vous connectez. Le message vous recommande d'utiliser un autre navigateur. Toutefois, de récentes versions de ces navigateurs ne prennent pas en charge NPAPI, il vous est donc impossible de les utiliser pour vous connecter à votre instance et vous devez choisir une autre méthode pour cela.

Pour en savoir plus, consultez les ressources suivantes :

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 essayer de pinger.

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.