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

Dans certaines conditions, il est possible qu'une instance Compute Engine n'accepte plus les connexions SSH. Cela peut arriver pour plusieurs raisons. Voici les causes les plus courantes de problèmes de connexion SSH :

  • La connexion au système d'exploitation est activée sur l'instance. Vous ne pouvez pas utiliser à la fois des clés SSH basées sur des métadonnées et une connexion à un système d'exploitation pour vous connecter à une instance. Si la connexion au système d'exploitation est activée, la connexion avec des clés SSH basées sur les métadonnées est désactivée. En effet, la connexion au système d'exploitation ne stocke pas les clés SSH dans les fichiers de clés autorisés.
  • La connexion au système d'exploitation n'est pas activée. Lorsque la connexion au système d'exploitation n'est pas activée, Google gère le fichier des clés autorisées pour les nouveaux comptes d'utilisateurs en fonction des clés SSH des métadonnées. Une instance Compute Engine n'accepte plus les connexions SSH à l'aide des clés SSH configurées dans le cadre de votre compte utilisateur.
    • Le daemon de comptes stocke un fichier dans l'invité pour conserver l'état des comptes utilisateur gérés par Google.
    • Le fichier des clés autorisées pour un compte utilisateur géré par Google est supprimé lorsque toutes les clés SSH du compte utilisateur sont supprimées des métadonnées.
    • Les comptes utilisateur qui ne sont pas gérés par Google ne sont pas modifiés par le daemon de comptes.
  • Le disque associé à l'instance est plein. Vérifiez votre espace disque et nettoyez-le si nécessaire.
  • Le daemon sshd n'est pas configuré correctement. Consultez le guide de l'utilisateur de votre système d'exploitation pour vous assurer que le fichier ssh_d est correctement configuré.

Cet article présente un certain nombre de conseils et d'approches permettant de résoudre certains des problèmes SSH les plus courants.

Exigences

Vous pouvez exécuter la plupart des étapes de dépannage à partir de votre poste de travail local. Pour dépanner une instance de VM depuis un poste de travail Linux ou Windows local, celui-ci doit d'abord être préparé.

Cette préparation s'effectue de la façon suivante :

  • Installez la dernière version de l'outil de ligne de commande gcloud ou appliquez la mise à jour correspondante.
  • Installez l'outil de détection et de sécurité réseau nmap correspondant à votre système d'exploitation. Cet outil va vous permettre de tester la connexion réseau à votre instance de VM.
  • Définir des variables d'environnement.

Définir des variables d'environnement

Des variables d'environnement peuvent être définies pour tous les paramètres utilisés fréquemment dans ce guide de dépannage, tels que le nom de l'instance et le nom du disque de démarrage persistant de l'instance affectée.

Définissez les variables d'environnement sur votre poste de travail local.

Linux ou macOS

Sur un poste de travail Linux ou macOS, utilisez la commande export.

export PROB_INSTANCE='instance-name'
export BOOT_DISK='boot-disk-name'

Remplacez l'élément suivant :

  • instance-name : nom de l'instance que vous dépannez ;
  • boot-disk-name : nom du disque de démarrage persistant de l'instance que vous dépannez.

Par exemple, si votre instance s'appelle instance1 et que votre disque de démarrage s'appelle disk1, exécutez les commandes suivantes :

export PROB_INSTANCE='instance1'
export BOOT_DISK='disk1'

Windows

Sous Windows, utilisez la commande set.

set PROB_INSTANCE='instance-name'
set BOOT_DISK='boot-disk-name'

Remplacez l'élément suivant :

  • instance-name : nom de l'instance que vous dépannez ;
  • boot-disk-name : nom du disque de démarrage persistant de l'instance que vous dépannez.

Par exemple, si votre instance s'appelle instance1 et que votre disque de démarrage s'appelle disk1, exécutez les commandes suivantes :

set PROB_INSTANCE='instance1'
set BOOT_DISK='disk1'

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 la règle de pare-feu par défaut autorisant les connexions SSH est supprimée, vous ne pourrez pas accéder à votre instance. Utilisez l'outil de ligne de commande gcloud compute pour vérifier la liste des pare-feu et assurez-vous que la règle default-allow-ssh est 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

Tester la connexion réseau

Vous pouvez utiliser l'outil nmap pour vous connecter à votre instance sur le port 22 et vérifier si la connexion réseau fonctionne. Si vous vous connectez et voyez 22/tcp open ssh, la connexion réseau fonctionne et vous pouvez éliminer les problèmes de pare-feu.

  1. Utilisez l'outil gcloud afin d'obtenir l'adresse IP externe natIP de votre instance :

    gcloud compute instances describe $PROB_INSTANCE
        --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
    198.51.100.1
    
  2. Testez la connexion réseau à votre instance.

    Exécutez la commande nmap pour tester la connexion réseau à votre instance, en remplaçant external-ip par l'adresse IP externe de l'instance :

    nmap external-ip
    

    Par exemple, si l'adresse IP externe est 198.51.100.1, exécutez la commande suivante :

    nmap 198.51.100.1
    Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-18 16:04 Greenwich Standard Time
    Nmap scan report for 229.30.196.35.bc.googleusercontent.com (198.51.100.1)
    Host is up (0.0061s latency).
    Not shown: 998 filtered ports
    PORT     STATE  SERVICE
    22/tcp   open   ssh
    Nmap done: 1 IP address (1 host up) scanned in 6.22 seconds
    

Connectez-vous 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 l'outil gcloud en spécifiant another-username dans la requête SSH. L'outil mettra à jour les métadonnées du projet pour ajouter le nouvel utilisateur et autoriser l'accès SSH.

gcloud compute ssh another-username@$PROB_INSTANCE

Résoudre le problème dans la console série

Nous vous recommandons de consulter les erreurs de connexion dans les journaux de la console série. Vous pouvez y accéder depuis votre poste de travail local à l'aide d'un navigateur.

Activez l'accès en lecture-écriture à la console série d'une instance afin de pouvoir vous connecter à la console et résoudre les problèmes liés à l'instance. Ceci est particulièrement 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 les deux situations.

Pour découvrir comment activer l'accès interactif et vous connecter à la console série d'une instance, consultez la page Interagir avec la console série.

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, vous devez prendre un instantané du disque de démarrage, créer un disque à partir de cet instantané, créer une instance temporaire, puis installer le nouveau disque persistant et l'associer à votre instance temporaire afin de dépanner le disque.

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

    gcloud compute networks create debug-network
    
  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
       --allow tcp:22
    
  3. Créez un instantané du disque de démarrage.

    gcloud compute disks snapshot $BOOT_DISK
       --snapshot-name debug-disk-snapshot
    
  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/$PROB_INSTANCE
    
    mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/$PROB_INSTANCE
    
    cd /mnt/$PROB_INSTANCE/var/log
    
    # Identify the issue preventing ssh from working
    ls
    

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 $PROB_INSTANCE
       --keep-disks boot
    
  2. Ajoutez une nouvelle instance avec le même disque et spécifiez le script de démarrage.

    gcloud compute instances create new-instance
       --disk name=$BOOT_DISK,boot=yes
       --startup-script-url URL
    

Pour commencer, vous pouvez utiliser le script compute-ssh-diagnostic afin de collecter des informations de diagnostic pour les problèmes les plus courants.

Utiliser le disque sur une nouvelle instance

Si les autres étapes de ce document ne fonctionnent pas et que vous devez 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.

gcloud compute instances delete $PROB_INSTANCE
    --keep-disks=boot

gcloud compute instances create new-instance
    --disk name=$BOOT_DISK,boot=yes,auto-delete=no

gcloud compute ssh new-instance