Résoudre les problèmes liés à SSH

Ce document décrit les erreurs courantes que vous pouvez rencontrer lorsque vous vous connectez à des instances de machines virtuelles (VM) à l'aide de SSH, les solutions pour y remédier et les méthodes de diagnostic des échecs de connexions SSH.

Outil de dépannage SSH

Utilisez l'outil de dépannage SSH pour déterminer la raison de l'échec de la connexion SSH. L'outil de dépannage effectue les tests suivants pour rechercher la cause des échecs de connexion SSH :

  • Tests des autorisations des utilisateurs : vérifient si vous disposez des autorisations IAM requises pour vous connecter à la VM à l'aide de SSH.
  • Tests de connectivité réseau : vérifient si la VM est connectée au réseau.
  • Tests de l'état de l'instance de VM : vérifient l'état du processeur de la VM pour savoir si la VM est en cours d'exécution.
  • Tests des paramètres VPC : vérifient le port SSH par défaut.

Exécuter l'outil de dépannage

Vous pouvez utiliser la console Google Cloud ou Google Cloud CLI pour résoudre les échecs de connexion SSH aux VM.

Console

Après une connexion SSH, vous avez la possibilité de relancer la connexion ou de résoudre les problèmes avec l'outil de dépannage SSH dans le navigateur.

Pour exécuter l'outil de dépannage, cliquez sur Résoudre les problèmes.

Lancement de l'outil de dépannage SSH.

gcloud

Exécutez l'outil de dépannage à l'aide de la commande gcloud compute ssh :

gcloud compute ssh VM_NAME \
    --troubleshoot

Remplacez VM_NAME par le nom de la VM à laquelle vous ne parvenez pas à vous connecter.

L'outil vous invite à fournir l'autorisation permettant d'effectuer les tests de dépannage.

Étudier les résultats

Après avoir exécuté l'outil de dépannage, procédez comme suit :

  1. Examinez les résultats du test pour comprendre pourquoi la connexion SSH de la VM ne fonctionne pas.
  2. Résolvez les connexions SSH en réalisant les mesures correctives fournies par l'outil.
  3. Essayez de vous reconnecter à la VM.

Erreurs courantes liées à SSH

Voici des exemples d'erreurs courantes que vous pouvez rencontrer lorsque vous utilisez SSH pour vous connecter à des VM Compute Engine.

Erreurs Linux

Autorisation refusée (clé publique)

L'erreur suivante peut se produire lorsque vous vous connectez à votre VM :

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Cette erreur peut se produire pour plusieurs raisons. Voici quelques-unes des causes les plus courantes de cette erreur :

  • Vous avez utilisé une clé SSH stockée dans les métadonnées pour vous connecter à une VM sur laquelle OS Login est activé. Si OS Login est activé sur votre projet, votre VM n'accepte pas les clés SSH stockées dans les métadonnées. Si vous ne savez pas si OS Login est activé, consultez la section Vérifier si OS Login est configuré.

    Pour résoudre ce problème, essayez l'une des solutions suivantes :

  • Vous avez utilisé une clé SSH stockée dans un profil OS Login pour vous connecter à une VM sur laquelle OS Login n'est pas activé. Si vous désactivez OS Login, votre VM n'accepte pas les clés SSH stockées dans votre profil OS Login. Si vous ne savez pas si OS Login est activé, consultez la section Vérifier si OS Login est configuré.

    Pour résoudre ce problème, essayez l'une des solutions suivantes :

  • OS Login est activé sur la VM, mais vous ne disposez pas des autorisations IAM suffisantes pour utiliser OS Login. Pour vous connecter à une VM sur laquelle OS Login est activé, vous devez disposer des autorisations requises pour OS Login. Si vous ne savez pas si OS Login est activé, consultez la section Vérifier si OS Login est configuré.

    Pour résoudre ce problème, accordez les rôles IAM OS Login requis.

  • Votre clé a expiré et Compute Engine a supprimé votre fichier ~/.ssh/authorized_keys. Si vous avez ajouté manuellement des clés SSH à votre VM, puis que vous vous êtes connecté à cette VM à l'aide de Google Cloud Console, Compute Engine a créé une paire de clés pour la connexion. Lorsque la nouvelle paire de clés a expiré, Compute Engine a supprimé le fichier ~/.ssh/authorized_keys de la VM, qui comprenait la clé SSH ajoutée manuellement.

    Pour résoudre ce problème, essayez l'une des solutions suivantes :

  • Vous vous êtes connecté à l'aide d'un outil tiers et votre commande SSH est mal configurée. Si vous vous connectez à l'aide de la commande ssh, mais que vous ne spécifiez pas de chemin d'accès à la clé privée, ou un chemin incorrect, votre VM refuse la connexion.

    Pour résoudre ce problème, essayez l'une des solutions suivantes :

    • Exécutez la commande suivante :
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP

      Remplacez les éléments suivants :
      • PATH_TO_PRIVATE_KEY : chemin d'accès au fichier de clé SSH privée.
      • USERNAME : nom de l'utilisateur qui se connecte à l'instance. Si vous gérez vos clés SSH dans les métadonnées, le nom d'utilisateur est celui que vous avez spécifié lorsque vous avez créé la clé SSH. Pour les comptes OS Login, le nom d'utilisateur est défini dans votre profil Google.
      • EXTERNAL_IP : adresse IP externe de votre VM.
    • Connectez-vous à votre VM à l'aide de Google Cloud Console ou de Google Cloud CLI. Lorsque vous utilisez ces outils pour vous connecter, Compute Engine gère la création des clés à votre place. Pour en savoir plus, consultez la page Se connecter à des VM.

  • L'environnement invité de votre VM n'est pas en cours d'exécution. Si vous vous connectez pour la première fois à votre VM et que l'environnement invité n'est pas en cours d'exécution, la VM peut refuser votre requête de connexion SSH.

    Pour résoudre ce problème, procédez comme suit :

    1. Redémarrez la VM.
    2. Dans la console Google Cloud, inspectez les journaux de démarrage du système dans la sortie du port série pour déterminer si l'environnement invité est en cours d'exécution. Pour en savoir plus, consultez la section Valider l'environnement invité.
    3. Si l'environnement invité n'est pas en cours d'exécution, installez-le manuellement en clonant le disque de démarrage de la VM et en utilisant un script de démarrage.

  • Le daemon sshd ne s'exécute pas ou n'est pas configuré correctement. Le daemon sshd active les connexions SSH. S'il est mal configuré ou ne s'exécute pas, vous ne pouvez pas vous connecter à votre VM.

    Pour résoudre ce problème, procédez comme suit :

    • Consultez le guide de l'utilisateur de votre système d'exploitation pour vous assurer que le fichier sshd_config est correctement configuré.

    • Si vous avez précédemment modifié les autorisations relatives aux dossiers sur votre VM, rétablissez les valeurs par défaut :

      • 700 sur le répertoire .ssh
      • 644 sur la clé publique, qui est stockée dans le dossier ~/.ssh/authorized_keys

      Connectez-vous à la console série de la VM en tant qu'utilisateur racine, puis modifiez les autorisations des dossiers suivants : 

      chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys

      Remplacez USERNAME par le nom d'utilisateur pour lequel vous souhaitez modifier les autorisations associées au dossier.

  • Le disque de démarrage de la VM est saturé. Lorsqu'une connexion SSH est établie, l'environnement invité ajoute la clé SSH publique de la session au fichier ~/.ssh/authorized_keys. Si le disque est saturé, la connexion échoue.

    Pour résoudre ce problème, essayez une ou plusieurs des solutions suivantes :

    • Vérifiez que le disque de démarrage est bien saturé en utilisant le débogage avec la console série pour identifier no space left errors.
    • Redimensionnez le disque.
    • Si vous savez quels fichiers consomment l'espace disque, créez un script de démarrage qui supprime les fichiers inutiles et libère de l'espace. Une fois que la VM a démarré et que vous êtes connecté, supprimez les métadonnées startup-script.

  • La propriété de $HOME, $HOME/.ssh ou $HOME/.ssh/authorized_keys, ou les autorisations qui y sont associées, sont incorrectes.

    • Propriété : l'environnement invité stocke la clé SSH publique d'un utilisateur dans le fichier $HOME/.ssh/authorized_keys. Le propriétaire du répertoire $HOME, du répertoire $HOME/.ssh et du fichier authorized_keys doit être l'utilisateur qui se connecte à la VM.

    • Autorisations Unix : l'environnement invité nécessite les autorisations Unix suivantes :

      Répertoire/Fichier Autorisation Unix requise
      Le répertoire $HOME 0755 ou 0700
      Le répertoire $HOME/.ssh 0700
      Le fichier authorized_keys 0600

Échec de la connexion

Les erreurs suivantes peuvent se produire lorsque vous vous connectez à votre VM depuis la console Google Cloud ou gcloud CLI :

  • La console Google Cloud :

    Connection Failed

We are unable to connect to the VM on port 22.

  • gcloud CLI :

    ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].

Ces erreurs peuvent se produire pour plusieurs raisons. Voici quelques-unes des causes d'erreur les plus courantes :

  • La VM démarre et sshd n'est pas encore en cours d'exécution. Vous ne pouvez pas vous connecter à une VM avant qu'elle ne soit en cours d'exécution.

    Pour résoudre ce problème, attendez que le démarrage de la VM soit terminé puis réessayez de vous connecter.

  • La règle de pare-feu autorisant SSH est manquante ou mal configurée. Par défaut, les VM Compute Engine autorisent l'accès SSH sur le port 22. Si la règle default-allow-ssh est manquante ou mal configurée, vous ne pourrez pas vous connecter aux VM.

    Pour résoudre ce problème, vérifiez vos règles de pare-feu puis ajoutez ou configurez de nouveau default-allow-ssh.

  • sshd s'exécute sur un port personnalisé. Si vous avez configuré sshd pour qu'il s'exécute sur un port autre que le port 22, vous ne pourrez pas vous connecter à votre VM.

    Pour résoudre ce problème, créez une règle de pare-feu personnalisée autorisant le trafic tcp sur le port sur lequel votre sshd s'exécute à l'aide de la commande suivante :

    gcloud compute firewall-rules create FIREWALL_NAME \
  --allow tcp:PORT_NUMBER

    Pour plus d'informations sur la création de règles de pare-feu personnalisées, consultez la section Créer des règles de pare-feu.

  • Votre règle de pare-feu SSH personnalisée n'autorise pas le trafic en provenance de services Google. Les connexions SSH à partir de la console Google Cloud sont refusées si les règles de pare-feu personnalisées n'autorisent pas les connexions à partir d'IAP ou de la plage d'adresses IP de Google.

    Pour résoudre ce problème, effectuez l'une des opérations suivantes :

    • Si vous utilisez Identity-Aware Proxy (IAP) pour le transfert TCP, mettez à jour votre règle de pare-feu personnalisée pour accepter le trafic provenant d'IAP, puis vérifiez vos autorisations IAM.

      1. Mettez à jour votre règle de pare-feu personnalisée pour autoriser le trafic provenant de 35.235.240.0/20, la plage d'adresses IP utilisée par IAP pour le transfert TCP. Pour plus d'informations, consultez la section Créer une règle de pare-feu.
      2. Accordez des autorisations pour utiliser le transfert TCP IAP, si ce n'est pas déjà fait.

    • Si vous n'utilisez pas IAP, mettez à jour votre règle de pare-feu personnalisée pour autoriser le trafic provenant de toute la plage d'adresses IP de Google.

      1. Mettez à jour votre règle de pare-feu personnalisée pour autoriser le trafic provenant d'adresses IP Google. Pour plus d'informations, consultez la section Mettre à jour des règles de pare-feu.

  • La connexion SSH a échoué après la mise à niveau du noyau de la VM. Une VM peut subir une panique du noyau après une mise à jour du noyau, ce qui la rend inaccessible.

    Pour résoudre ce problème, procédez comme suit :

    1. Installez le disque sur une autre VM.
    2. Mettez à jour le fichier grub.cfg pour utiliser la version précédente du noyau.
    3. Rattachez le disque à la VM qui ne répond pas.
    4. Vérifiez que l'état de la VM est bien RUNNING en utilisant la commande gcloud compute instances describe.
    5. Réinstallez le noyau.
    6. Redémarrez la VM.

    Si vous avez créé un instantané du disque de démarrage avant de mettre à niveau la VM, vous pouvez également utiliser l'instantané pour créer une VM.

  • Le daemon sshd ne s'exécute pas ou n'est pas configuré correctement. Le daemon sshd active les connexions SSH. S'il est mal configuré ou ne s'exécute pas, vous ne pouvez pas vous connecter à votre VM.

    Pour résoudre ce problème, procédez comme suit :

    • Consultez le guide de l'utilisateur de votre système d'exploitation pour vous assurer que le fichier sshd_config est correctement configuré.

    • Si vous avez précédemment modifié les autorisations relatives aux dossiers sur votre VM, rétablissez les valeurs par défaut :

      • 700 sur le répertoire .ssh
      • 644 sur la clé publique, qui est stockée dans le dossier ~/.ssh/authorized_keys

      Connectez-vous à la console série de la VM en tant qu'utilisateur racine, puis modifiez les autorisations des dossiers suivants : 

      chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys

      Remplacez USERNAME par le nom d'utilisateur pour lequel vous souhaitez modifier les autorisations associées au dossier.

  • La VM ne démarre pas et vous ne pouvez pas vous connecter via SSH ou la console série. Si la VM est inaccessible, votre système d'exploitation est peut-être corrompu. Si le disque de démarrage ne démarre pas, vous pouvez diagnostiquer le problème. Si vous souhaitez récupérer la VM corrompue et récupérer les données, consultez la section Récupérer une VM corrompue ou un disque de démarrage complet.

  • La VM démarre en mode de maintenance. Lors du démarrage en mode de maintenance, la VM n'accepte pas les connexions SSH, mais vous pouvez vous connecter à la console série de la VM et vous connecter en tant qu'utilisateur racine.

    Pour résoudre ce problème, procédez comme suit :

    1. Si vous n'avez pas défini de mot de passe racine pour la VM, utilisez un script de démarrage des métadonnées pour exécuter la commande suivante au démarrage :

      echo "NEW_PASSWORD" | chpasswd

      Remplacez NEW_PASSWORD par le mot de passe de votre choix.

    2. Redémarrez la VM.

    3. Connectez-vous à la console série de la VM, puis connectez-vous en tant qu'utilisateur racine.

Échec de la connexion au backend

Les erreurs suivantes peuvent se produire lorsque vous vous connectez à votre VM depuis la console Google Cloud ou gcloud CLI :

  • La console Google Cloud :

    -- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

  • gcloud CLI :

    ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: u'failed to connect to backend'].

Ces erreurs se produisent lorsque vous essayez d'utiliser SSH pour vous connecter à une VM qui ne possède pas d'adresse IP publique et pour laquelle vous n'avez pas configuré Identity-Aware Proxy sur le port 22.

Pour résoudre ce problème, créez une règle de pare-feu sur le port 22 autorisant le trafic entrant provenant d'Identity-Aware Proxy.

La clé d'hôte ne correspond pas

L'erreur suivante peut se produire lorsque vous vous connectez à votre VM :

Host key for server IP_ADDRESS does not match

Cette erreur se produit lorsque la clé d'hôte dans le fichier ~/.ssh/known_hosts ne correspond pas à la clé d'hôte de la VM.

Pour résoudre ce problème, supprimez la clé d'hôte du fichier ~/.ssh/known_hosts, puis réessayez d'établir la connexion.

La valeur des métadonnées est trop élevée

L'erreur suivante peut se produire lorsque vous essayez d'ajouter une nouvelle clé SSH aux métadonnées :

ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."

Les valeurs de métadonnées ont une limite maximale de 256 ko. Pour contourner cette limitation, effectuez l'une des opérations suivantes :

Erreurs Windows

Autorisation refusée. Veuillez réessayer.

L'erreur suivante peut se produire lorsque vous vous connectez à votre VM :

USERNAME@compute.INSTANCE_ID's password:
Permission denied, please try again.

Cette erreur indique que l'utilisateur qui tente de se connecter à la VM n'existe pas sur celle-ci. Voici quelques-unes des causes les plus courantes de cette erreur :

  • Votre version de gcloud CLI est obsolète

    Si gcloud CLI est obsolète, vous essayez peut-être de vous connecter à l'aide d'un nom d'utilisateur non configuré. Pour résoudre ce problème, mettez à jour gcloud CLI.

  • Vous avez essayé de vous connecter à une VM Windows sur laquelle SSH n'est pas activé

    Pour résoudre cette erreur, définissez la clé enable-windows-ssh sur TRUE dans les métadonnées du projet ou de l'instance. Pour en savoir plus sur la définition des métadonnées, consultez la page Définir des métadonnées personnalisées.

Autorisation refusée (clé publique, authentification via le clavier)

L'erreur suivante peut se produire lorsque vous vous connectez à une VM sur laquelle SSH n'est pas activé :

Permission denied (publickey,keyboard-interactive).

Pour résoudre cette erreur, définissez la clé enable-windows-ssh sur TRUE dans les métadonnées du projet ou de l'instance. Pour en savoir plus sur la définition des métadonnées, consultez la page Définir des métadonnées personnalisées.

Impossible de se connecter via SSH à l'instance

L'erreur suivante peut se produire lorsque vous vous connectez à votre VM depuis gcloud CLI :

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.
It is possible that your SSH key has not propagated to the instance yet.
Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

Cette erreur peut se produire pour plusieurs raisons. Voici quelques-unes des causes d'erreur les plus courantes :

Connexion expirée

L'expiration des connexions SSH peut être due à l'une des raisons suivantes :

  • Le démarrage de la VM n'est pas terminé. Patientez un court instant le temps que la VM démarre.

    Pour résoudre ce problème, attendez que le démarrage de la VM soit terminé puis réessayez de vous connecter.

  • Le package SSH n'est pas installé. Les VM Windows nécessitent l'installation du package google-compute-engine-ssh pour que vous puissiez vous connecter via SSH.

    Pour résoudre ce problème, installez le package SSH.

Diagnostiquer les échecs de connexions SSH

Les sections suivantes décrivent les procédures à suivre pour diagnostiquer la cause des échecs de connexions SSH et résoudre les problèmes de connexion.

Avant de diagnostiquer les échecs de connexions SSH, procédez comme suit :

Méthodes de diagnostic pour les VM Linux et Windows

Tester la connectivité

Il est possible que vous ne puissiez pas utiliser SSH sur une instance de VM en raison de problèmes de connectivité liés aux pare-feu, à la connexion réseau ou au compte utilisateur. Dans ce cas, suivez les étapes de cette section pour identifier les problèmes de connectivité.

Vérifier les règles de pare-feu

Compute Engine provisionne chaque projet avec des règles de pare-feu par défaut qui autorisent le trafic SSH. Si vous ne parvenez pas à accéder à votre instance, utilisez l'outil de ligne de commande gcloud compute pour vérifier votre liste de pare-feu et vous assurer que la règle default-allow-ssh est bien présente.

Sur votre poste de travail local, exécutez la commande suivante :

gcloud compute firewall-rules list

Si elle est absente, ajoutez-la :

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

Pour afficher toutes les données associées à la règle de pare-feu default-allow-ssh de votre projet, exécutez la commande gcloud compute firewall-rules describe :

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

Pour en savoir plus sur les règles de pare-feu, consultez la section Règles de pare-feu dans Google Cloud.

Tester la connexion réseau

Pour déterminer si la connexion réseau fonctionne, testez le handshake TCP :

  1. Obtenez le natIP externe pour votre VM :

    gcloud compute instances describe VM_NAME \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)'

    Remplacez VM_NAME par le nom de la VM à laquelle vous ne parvenez pas à vous connecter.

  2. Testez la connexion réseau à votre VM depuis votre poste de travail :

    Linux, Windows 2019/2022 et macOS 

    curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER

    Remplacez les éléments suivants :

    • EXTERNAL_IP : adresse IP externe obtenue à l'étape précédente.
    • PORT_NUMBER : numéro de port.

    Si le handshake TCP réussit, le résultat est semblable à celui-ci :

    Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
Trying 192.168.0.4...
TCP_NODELAY set
Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
> GET / HTTP/1.1
> Host: 192.168.0.4:443
> User-Agent: curl/7.64.0
> Accept: */*
>
Empty reply from server
Connection #0 to host 192.168.0.4 left intact

    La ligne Connected to indique un handshake TCP ayant réussi.

    Windows 2012 et 2016

    PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)

    Remplacez les éléments suivants :

    • EXTERNAL_IP : adresse IP externe obtenue à l'étape précédente.
    • PORT_NUMBER : numéro de port.

    Si le handshake TCP réussit, le résultat est semblable à celui-ci :

    Available           : 0
Client              : System.Net.Sockets.Socket
Connected           : True
ExclusiveAddressUse : False
ReceiveBufferSize   : 131072
SendBufferSize      : 131072
ReceiveTimeout      : 0
SendTimeout         : 0
LingerState         : System.Net.Sockets.LingerOption
NoDelay             : False

    La ligne Connected: True indique un handshake TCP ayant réussi.

Si le handshake TCP a abouti, il n'y a pas de règle de pare-feu logicielle bloquant la connexion, le système d'exploitation transmet correctement les paquets et un serveur écoute sur le port de destination. Si le handshake TCP a abouti, mais que la VM n'accepte pas les connexions SSH, le problème peut être dû au fait que le daemon sshd est mal configuré ou ne s'exécute pas correctement. Consultez le guide de l'utilisateur de votre système d'exploitation pour vous assurer que le fichier sshd_config est correctement configuré.

Pour exécuter des tests de connectivité afin d'analyser la configuration du chemin du réseau VPC entre deux VM et vérifier si la configuration programmée doit autoriser le trafic, consultez la page Rechercher les règles de pare-feu mal configurées dans Google Cloud.

Se connecter avec un autre compte utilisateur

Le problème qui vous empêche de vous connecter peut provenir de votre compte d'utilisateur. Par exemple, les autorisations sur l'instance spécifiées dans le fichier ~/.ssh/authorized_keys n'ont pas été définies correctement pour cet utilisateur.

Essayez de vous connecter en tant qu'utilisateur différent à l'aide de gcloud CLI en spécifiant ANOTHER_USERNAME dans la requête SSH. gcloud CLI met à jour les métadonnées du projet pour ajouter le nouvel utilisateur et autoriser l'accès SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Remplacez les éléments suivants :

  • ANOTHER_USERNAME est un nom d'utilisateur autre que le vôtre.
  • VM_NAME est le nom de la VM à laquelle vous souhaitez vous connecter.

Résoudre les problèmes à l'aide de la console série

Nous vous recommandons de consulter les erreurs de connexion dans les journaux de la console série. Vous pouvez accéder à la console série en tant qu'utilisateur racine depuis votre poste de travail local à l'aide d'un navigateur. Cette approche est utile lorsque vous ne pouvez pas vous connecter avec SSH ou si l'instance ne dispose d'aucune connexion au réseau. La console série reste accessible dans ces deux situations.

Pour vous connecter à la console série de la VM et résoudre les problèmes liés à la VM, procédez comme suit :

  1. Activez l'accès interactif à la console série de la VM.

  2. Pour les VM Linux, modifiez le mot de passe racine, puis ajoutez le script de démarrage suivant à votre VM : 

    usermod -p $(echo "PASSWORD" | openssl passwd -1 -stdin) root
     Remplacez PASSWORD par le mot de passe de votre choix.

  3. Utilisez la console série pour vous connecter à votre VM.

  4. Pour les VM Linux, une fois le débogage de toutes les erreurs terminé, désactivez la connexion du compte racine : 

    sudo passwd -l root

Méthodes de diagnostic pour les VM Linux

Inspecter une instance de VM sans l'arrêter

Il se peut que vous ne puissiez pas vous connecter à une instance qui continue de diffuser correctement le trafic de production. Dans ce cas, vous pouvez tenter d'inspecter le disque sans interrompre l'instance.

Pour inspecter le disque et résoudre les problèmes, procédez comme suit :

  1. Sauvegardez votre disque de démarrage en créant un instantané du disque.
  2. Créez un disque persistant standard à partir de cet instantané.
  3. Créez une instance temporaire.
  4. Associez le disque persistant standard à votre nouvelle instance temporaire et installez-le sur celle-ci.

Cette procédure crée un réseau isolé qui n'autorise que les connexions SSH. Cette configuration évite les conséquences imprévues des interférences de l'instance clonée avec les services de production.

  1. Créez un réseau VPC pour héberger l'instance clonée :

    gcloud compute networks create debug-network

    Remplacez NETWORK_NAME par le nom que vous souhaitez donner à votre nouveau réseau.

  2. Ajoutez une règle de pare-feu pour autoriser les connexions SSH au réseau :

    gcloud compute firewall-rules create debug-network-allow-ssh \
   --network debug-network \
   --allow tcp:22

  3. Créez un instantané du disque de démarrage.

    gcloud compute disks snapshot BOOT_DISK_NAME \
   --snapshot-names debug-disk-snapshot

    Remplacez BOOT_DISK_NAME par le nom du disque de démarrage.

  4. Créez un disque avec l'instantané que vous venez de générer :

    gcloud compute disks create example-disk-debugging \
   --source-snapshot debug-disk-snapshot

  5. Créez une instance de débogage sans adresse IP externe :

    gcloud compute instances create debugger \
   --network debug-network \
   --no-address

  6. Associez le disque de débogage à l'instance :

    gcloud compute instances attach-disk debugger \
   --disk example-disk-debugging

  7. Suivez les instructions pour vous connecter à une instance sans adresse IP externe.

  8. Une fois connecté à l'instance de débogage, dépannez l'instance. Par exemple, vous pouvez consulter les journaux de l'instance :

    sudo su -

    mkdir /mnt/VM_NAME

    mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME

    cd /mnt/VM_NAME/var/log

    # Identify the issue preventing ssh from working
ls

    Remplacez VM_NAME par le nom de la VM à laquelle vous ne parvenez pas à vous connecter.

Utiliser un script de démarrage

Si aucune des solutions précédentes ne vous aide, vous pouvez créer un script de démarrage pour collecter des informations juste après le démarrage de l'instance. Suivez les instructions pour exécuter un script de démarrage.

Vous devez ensuite réinitialiser votre instance avant que les métadonnées ne soient affectées en exécutant la commande gcloud compute instances reset.

Vous pouvez également recréer l'instance avec un script de démarrage de diagnostic :

  1. Exécutez gcloud compute instances delete avec l'indicateur --keep-disks.

    gcloud compute instances delete VM_NAME \
   --keep-disks boot

    Remplacez VM_NAME par le nom de la VM à laquelle vous ne parvenez pas à vous connecter.

  2. Ajoutez une nouvelle instance avec le même disque et spécifiez le script de démarrage.

    gcloud compute instances create NEW_VM_NAME \
   --disk name=BOOT_DISK_NAME,boot=yes \
   --metadata startup-script-url URL

    Remplacez les éléments suivants :

    • NEW_VM_NAME est le nom de la VM que vous créez.
    • BOOT_DISK_NAME est le nom du disque de démarrage de la VM à laquelle vous ne parvenez pas à vous connecter.
    • URL est l'URL Cloud Storage d'accès au script, au format gs://BUCKET/FILE ou https://storage.googleapis.com/BUCKET/FILE.

Utiliser le disque sur une nouvelle instance

Si vous devez toujours récupérer des données à partir de votre disque de démarrage persistant, vous pouvez dissocier le disque de démarrage, puis l'associer à une nouvelle instance en tant que disque secondaire.

  1. Supprimez la VM à laquelle vous ne parvenez pas à vous connecter et conservez son disque de démarrage :

    gcloud compute instances delete VM_NAME \
   --keep-disks=boot

    Remplacez VM_NAME par le nom de la VM à laquelle vous ne parvenez pas à vous connecter.

  2. Créez une VM avec le disque de démarrage de l'ancienne VM. Spécifiez le nom du disque de démarrage de la VM que vous venez de supprimer.

  3. Connectez-vous à votre VM à l'aide de SSH :

    gcloud compute ssh NEW_VM_NAME

    Remplacez NEW_VM_NAME par le nom de votre nouvelle VM.

Vérifier si le disque de démarrage de la VM est saturé

Votre VM peut devenir inaccessible si son disque de démarrage est saturé. Ce scénario peut être difficile à identifier : il n'est pas toujours évident de savoir si le problème de connectivité des VM est dû à un disque de démarrage saturé. Pour plus d'informations sur ce scénario, consultez la section Dépannage d'une VM inaccessible en raison d'un disque de démarrage saturé.

Méthodes de diagnostic pour les VM Windows

Réinitialiser les métadonnées SSH

Si vous ne pouvez pas vous connecter à une VM Windows à l'aide de SSH, annulez la définition de la clé de métadonnées enable-windows-ssh et réactivez SSH pour Windows.

  1. Définissez la clé de métadonnées enable-windows-ssh sur FALSE. Pour en savoir plus sur la définition des métadonnées, consultez la page Définir des métadonnées personnalisées.

    Attendez quelques secondes que la modification prenne effet.

  2. Réactivez SSH pour Windows.

  3. Reconnectez-vous à la VM.

Se connecter à la VM à l'aide de RDP

Si vous ne parvenez pas à diagnostiquer et à résoudre la cause des échecs des connexions SSH à votre VM Windows, connectez-vous à l'aide de RDP.

Une fois la connexion à la VM établie, consultez les journaux OpenSSH.

Étape suivante