Risoluzione degli errori SSH

Questo documento descrive gli errori comuni che potresti riscontrare durante la connessione a di macchine virtuali (VM) tramite SSH, come risolvere gli errori per diagnosticare le connessioni SSH non riuscite.

Strumento per la risoluzione dei problemi relativi a SSH

Utilizza lo strumento per la risoluzione dei problemi SSH per determinare il motivo per cui la connessione SSH non è riuscita. Lo strumento di risoluzione dei problemi esegue i seguenti test per verificare la causa delle connessioni SSH non riuscite:

  • Test delle autorizzazioni utente: verifica se disponi dei file IAM richiesti per connetterti alla VM tramite SSH.
  • Test di connettività di rete: controlla se la VM è connessa alla rete.
  • Test dello stato dell'istanza VM: controlla lo stato della CPU della VM per capire se in esecuzione.
  • Test delle impostazioni VPC: controlla la porta SSH predefinita.

Esegui lo strumento di risoluzione dei problemi

Puoi utilizzare la console Google Cloud o Google Cloud CLI per verificare problemi di rete ed errori di autorizzazione degli utenti che potrebbero causare l'accesso SSH delle connessioni non riuscite.

Console

Se una connessione SSH non riesce, puoi scegliere Riprova per eseguire la o risolvere i problemi di connessione mediante SSH nel browser strumento per la risoluzione dei problemi.

Per eseguire lo strumento di risoluzione dei problemi, fai clic su Risolvi i problemi.

Avvia lo strumento per la risoluzione dei problemi relativi a SSH.

gcloud

Esegui lo strumento di risoluzione dei problemi utilizzando Comando gcloud compute ssh:

gcloud compute ssh VM_NAME \
    --troubleshoot

Sostituisci VM_NAME con il nome della VM che non riesce a connettersi.

Lo strumento ti chiede di fornire l'autorizzazione per eseguire la risoluzione dei problemi. test.

Esaminare i risultati

Dopo aver eseguito lo strumento di risoluzione dei problemi, procedi nel seguente modo:

  1. Esamina i risultati del test per capire perché la connessione SSH della VM non funziona.
  2. Risolvi le connessioni SSH eseguendo i passaggi di correzione forniti da lo strumento.

  3. Prova a riconnetterti alla VM.

    Se la connessione non riesce, prova a risolvere manualmente il problema svolgendo le seguenti:

Errori SSH comuni

Di seguito sono riportati alcuni esempi di errori comuni che potresti riscontrare quando utilizzi SSH. per la connessione alle VM di Compute Engine.

Errori SSH nel browser

Errore 401 non autorizzato

Potrebbe verificarsi il seguente errore quando ti connetti alla VM utilizzando SSH nel browser da la console Google Cloud:

Unauthorized
Error 401

Questo errore si verifica se l'utente fa parte di un'organizzazione che gestiti dall'interno di Google Workspace ed è presente limitazione nel criterio di Workspace che impedisce agli utenti di che accede a SSH nel browser e alla console seriale in Google Cloud.

Per risolvere il problema, chiedi a un amministratore di Google Workspace di procedere nel seguente modo:

  1. Verifica che Google Cloud sia abilitato per l'organizzazione.

    Se Google Cloud è disabilitato, abilitalo e riprova a stabilire la connessione.

  2. Verifica che i servizi non controllabili individualmente siano attivati.

    Se questi servizi sono disabilitati, abilitali e riprova a stabilire la connessione.

Se il problema persiste dopo aver abilitato le impostazioni di Google Cloud in Google Workspace, segui questi passaggi:

  1. Acquisire il traffico di rete in un file HAR (HTTP Archive Format) a partire dall'avvio della connessione SSH nel browser.

  2. Crea una richiesta di assistenza clienti Google Cloud e allega il file HAR.

Impossibile connettersi, nuovo tentativo in corso...

All'avvio di una sessione SSH può verificarsi il seguente errore: 

Could not connect, retrying ...

Impossibile connettersi, nuovo tentativo in corso

Per risolvere il problema:

  1. Al termine dell'avvio della VM, riprova a stabilire la connessione. Se connessione non riuscita, verifica che la VM non sia stata avviata in modalità di emergenza eseguendo il comando seguente:

    gcloud compute instances get-serial-port-output VM_NAME \
| grep "emergency mode"

    Se la VM si avvia in modalità di emergenza, risolvi i problemi relativi al processo di avvio della VM per identificare dove si verifica l'errore.

  2. Verifica che il servizio google-guest-agent.service sia in esecuzione eseguendo questo comando nella console seriale.

    systemctl status google-guest-agent.service

    Se il servizio è disabilitato, abilitalo e avvialo eseguendo questi comandi:

    systemctl enable google-guest-agent.service
systemctl start google-guest-agent.service

  3. Verifica che gli script dell'agente Google Linux siano installati e in esecuzione. Per ulteriori informazioni, vedi Determinazione dello stato dell'agente Google. Se l'agente Google Linux non è installato, reinstallala.

  4. Verifica di disporre dei ruoli richiesti per connetterti alla VM. Se la VM utilizza OS Login, consulta l'articolo Assegnare il ruolo IAM OS Login. Se la VM non utilizza OS Login, devi avere il ruolo di amministratore istanze di calcolo o il ruolo utente dell'account di servizio (se la VM è configurata per essere eseguita come (account di servizio). I ruoli sono necessari per aggiornare l'istanza chiavi-metadati SSH del progetto.

  5. Verifica che esista una regola firewall che consenta l'accesso SSH eseguendo questo comando:

    gcloud compute firewall-rules list | grep "tcp:22"

  6. Verifica che esista una route predefinita verso internet (o al bastione) ). Per ulteriori informazioni, vedi Verificare i percorsi.

  7. Assicurati che lo spazio su disco del volume principale non sia esaurito. Per ulteriori informazioni, vedi Risoluzione dei problemi relativi ai dischi completi e al ridimensionamento dei dischi.

  8. Assicurati che la VM non abbia esaurito la memoria eseguendo questo comando:

    gcloud compute instances get-serial-port-output instance-name \
| grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"

    Se la VM ha esaurito la memoria, connettiti alla console seriale per risolvere i problemi.

Errori Linux

Autorizzazione negata (publickey)

Quando ti connetti alla VM potrebbe verificarsi il seguente errore:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

Questo errore può verificarsi per diversi motivi. Di seguito sono riportati alcuni dei cause comuni di questo errore:

  • Hai utilizzato una chiave SSH archiviata nei metadati per connetterti a una VM con OS Login attivata. Se OS Login è abilitato nel tuo progetto, la tua VM non accetta Chiavi SSH archiviate nei metadati. Se non sai con certezza se OS Login è attiva, consulta Controllare se OS Login è configurato.

    Per risolvere il problema, prova una delle seguenti soluzioni:

  • Hai utilizzato una chiave SSH archiviata in un profilo OS Login per connetterti a una VM non ha OS Login abilitato. Se disabiliti OS Login, la VM non accettare chiavi SSH memorizzate nel tuo profilo di OS Login. In caso di dubbi Se OS Login è abilitato, consulta Controllare se OS Login è configurato.

    Per risolvere il problema, prova una delle seguenti soluzioni:

  • Nella VM è abilitato OS Login, ma non disponi di autorizzazioni IAM sufficienti per utilizzare OS Login. Per connetterti a una VM in cui OS Login è abilitato, devi avere le autorizzazioni richieste per OS Login. Se non sai con certezza se OS Login attiva, consulta Controllare se OS Login è configurato.

    Per risolvere il problema, concedere i ruoli IAM OS Login richiesti.

  • La chiave è scaduta e Compute Engine ha eliminato il tuo ~/.ssh/authorized_keys . Se hai aggiunto manualmente chiavi SSH alla VM e poi ti sei connesso utilizzando la console Google Cloud, Compute Engine ha creato una nuova coppia di chiavi la connessione. Dopo la scadenza della nuova coppia di chiavi, Compute Engine ha eliminato il file ~/.ssh/authorized_keys nella VM, che includeva una chiave SSH aggiunta manualmente.

    Per risolvere il problema, prova una delle seguenti soluzioni:

  • Hai effettuato la connessione tramite uno strumento di terze parti e il tuo comando SSH non è configurata correttamente. Se ti connetti utilizzando il comando ssh, ma non specifichi un percorso alla tua chiave privata oppure specifichi un percorso errato la VM rifiuta la connessione.

    Per risolvere il problema, prova una delle seguenti soluzioni:

    • Esegui questo comando:
      ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP

      Sostituisci quanto segue:
      • PATH_TO_PRIVATE_KEY: il valore del tuo file di chiave SSH privato.
      • USERNAME: il nome utente dell'utente che si connette all'istanza. Se gestisci le chiavi SSH nei metadati, è quello che hai specificato ha creato la chiave SSH. Per gli account OS Login: il nome utente è definito nel tuo profilo Google.
      • EXTERNAL_IP: l'indirizzo IP esterno del tuo VM.
    • Connettiti alla VM utilizzando la console Google Cloud o Google Cloud CLI. Quando che usi per connetterti, Compute Engine gestisce la creazione delle chiavi te. Per ulteriori informazioni, vedi Connessione alle VM.

  • L'ambiente guest della tua VM non è in esecuzione. Se è la prima volta che ti connetti alla VM e l'ambiente guest non è in esecuzione, la VM potrebbe rifiutare la richiesta di connessione SSH.

    Per risolvere il problema:

    1. Riavvia la VM.
    2. Nella console Google Cloud, esamina i log di avvio del sistema porta seriale per determinare se l'ambiente guest è in esecuzione. Per ulteriori informazioni, consulta Convalida dell'ambiente guest.
    3. Se l'ambiente guest non è in esecuzione, installalo manualmente clonando il disco di avvio della VM e utilizzando uno script di avvio.

  • Il daemon OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. La sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se si tratta configurato in modo errato o non in esecuzione, non puoi connetterti alla VM tramite SSH.

    Per risolvere il problema, prova una o più delle seguenti operazioni:

    • Consulta la guida dell'utente relativa al tuo sistema operativo per assicurarti che le tue sshd_config sia configurato correttamente.

    • Assicurati di disporre delle impostazioni di proprietà e autorizzazione necessarie per seguenti:

      • Directory $HOME e $HOME/.ssh
      • File $HOME/.ssh/authorized_keys

      Proprietà

      L'ambiente guest archivia le chiavi pubbliche SSH autorizzate $HOME/.ssh/authorized_keys. Il proprietario di $HOME e $HOME/.ssh e il file $HOME/.ssh/authorized_keys deve essere identico al file che si connette alla VM.

      Autorizzazioni

      L'ambiente guest richiede le seguenti autorizzazioni Linux:

      Percorso Autorizzazioni
      /home 0755
      $HOME 0700, 0750 o 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Per scoprire quale opzione è il valore predefinito corretto autorizzazione per la directory $HOME, consulta la documentazione ufficiale per della tua distribuzione Linux specifica.

      In alternativa, puoi creare una nuova VM basata sulla stessa immagine e verificarne la autorizzazioni predefinite per $HOME.

      Per scoprire come modificare le autorizzazioni e la proprietà, consulta chmod e chown.

    • Riavvia sshd eseguendo questo comando:

      systemctl restart sshd.service

      Verifica se ci sono errori nello stato eseguendo questo comando:

      systemctl status sshd.service

      L'output dello stato può contenere informazioni quali il codice di uscita, il motivo per l'errore e così via. Puoi usare questi dettagli per risolvere altri problemi.

  • Il disco di avvio della VM è pieno. Quando viene stabilita una connessione SSH, l'ambiente guest aggiunge la chiave SSH pubblica della sessione ~/.ssh/authorized_keys. Se il disco è pieno, la connessione non riesce.

    Per risolvere il problema, esegui una o più delle seguenti operazioni:

  • Le autorizzazioni o la proprietà su $HOME, $HOME/.ssh o $HOME/.ssh/authorized_keys non è corretto.

    Proprietà

    L'ambiente guest archivia le chiavi pubbliche SSH autorizzate $HOME/.ssh/authorized_keys. Il proprietario di $HOME e $HOME/.ssh e il file $HOME/.ssh/authorized_keys deve essere identico al file che si connette alla VM.

    Autorizzazioni

    L'ambiente guest richiede le seguenti autorizzazioni Linux:

    Percorso Autorizzazioni
    /home 0755
    $HOME 0700, 0750 o 0755 *
    $HOME/.ssh 0700
    $HOME/.ssh/authorized_keys 0600

    * Per scoprire quale opzione è il valore predefinito corretto autorizzazione per la directory $HOME, consulta la documentazione ufficiale per della tua distribuzione Linux specifica.

    In alternativa, puoi creare una nuova VM basata sulla stessa immagine e verificarne la autorizzazioni predefinite per $HOME.

    Per scoprire come modificare le autorizzazioni e la proprietà, consulta chmod e chown.

Connessione non riuscita

Potrebbero verificarsi i seguenti errori quando ti connetti alla VM dalla console Google Cloud, gcloud CLI, un bastion host o un server cliente:

  • 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].

  • Un bastion host o un client locale:

    port 22: Connection timed out.

    port 22: Connection refused

Questi errori possono verificarsi per diversi motivi. Di seguito sono riportati alcuni dei cause comuni degli errori:

  • La VM è in fase di avvio e sshd non è ancora in esecuzione. Non puoi connettersi a una VM prima che sia in esecuzione.

    Per risolvere il problema, attendi il termine dell'avvio della VM e prova a connettiti di nuovo.

  • sshd è in esecuzione su una porta personalizzata. Se hai configurato sshd per l'esecuzione su un diversa dalla porta 22, non potrai connetterti alla VM.

    Per risolvere il problema, crea una regola firewall personalizzata che consenta il traffico di tcp la porta su cui è in esecuzione il tuo sshd utilizzando il seguente comando:

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

    Per ulteriori informazioni sulla creazione di regole firewall personalizzate, consulta Creazione di regole firewall.

  • La regola firewall SSH non è presente o non consente il traffico da IAP o la rete internet pubblica. le connessioni SSH vengono rifiutate se Le regole firewall non consentono connessioni da IAP o TCP in entrata traffico per l'intervallo IP 0.0.0.0/0.

    Per risolvere il problema, procedi in uno dei seguenti modi:

    • Se utilizzi Identity-Aware Proxy (IAP) per l'inoltro TCP, aggiorna il tuo una regola firewall per accettare il traffico da IAP, quindi controlla IAM autorizzazioni aggiuntive.

      1. Aggiorna la regola firewall personalizzata per consentire il traffico proveniente da 35.235.240.0/20, l'intervallo di indirizzi IP che IAP utilizza per l'inoltro TCP. Per ulteriori informazioni, vedi Crea una regola firewall.
      2. Concedi le autorizzazioni per utilizzare l'inoltro TCP IAP, se non l'hai ancora fatto.

    • Se non utilizzi IAP, aggiorna la regola firewall personalizzata in per consentire il traffico SSH in entrata.

      1. Aggiorna la regola firewall personalizzata a Consenti le connessioni SSH in entrata alle VM.

  • La connessione SSH non è riuscita dopo l'upgrade del kernel della VM. Una VM può un panic del kernel dopo un aggiornamento del kernel, con il conseguente ridimensionamento della VM inaccessibili.

    Per risolvere il problema:

    1. Installa il disco su un altro VM.
    2. Aggiorna il file grub.cfg per usare la versione precedente del kernel.
    3. Collega il disco a la VM che non risponde.
    4. Verifica che lo stato della VM sia RUNNING utilizzando Comando gcloud compute instances describe.
    5. Reinstalla il kernel.
    6. Riavvia la VM.

    In alternativa, se hai creato uno snapshot del disco di avvio prima Esegui l'upgrade della VM, utilizza lo snapshot per creare una VM.

  • Il daemon OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. La sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se si tratta configurato in modo errato o non in esecuzione, non puoi connetterti alla VM tramite SSH.

    Per risolvere il problema, prova una o più delle seguenti operazioni:

    • Consulta la guida dell'utente relativa al tuo sistema operativo per assicurarti che le tue sshd_config sia configurato correttamente.

    • Assicurati di disporre delle impostazioni di proprietà e autorizzazione necessarie per seguenti:

      • Directory $HOME e $HOME/.ssh
      • File $HOME/.ssh/authorized_keys

      Proprietà

      L'ambiente guest archivia le chiavi pubbliche SSH autorizzate $HOME/.ssh/authorized_keys. Il proprietario di $HOME e $HOME/.ssh e il file $HOME/.ssh/authorized_keys deve essere identico al file che si connette alla VM.

      Autorizzazioni

      L'ambiente guest richiede le seguenti autorizzazioni Linux:

      Percorso Autorizzazioni
      /home 0755
      $HOME 0700, 0750 o 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Per scoprire quale opzione è il valore predefinito corretto autorizzazione per la directory $HOME, consulta la documentazione ufficiale per della tua distribuzione Linux specifica.

      In alternativa, puoi creare una nuova VM basata sulla stessa immagine e verificarne la autorizzazioni predefinite per $HOME.

      Per scoprire come modificare le autorizzazioni e la proprietà, consulta chmod e chown.

    • Riavvia sshd eseguendo questo comando:

      systemctl restart sshd.service

      Verifica se ci sono errori nello stato eseguendo questo comando:

      systemctl status sshd.service

      L'output dello stato può contenere informazioni quali il codice di uscita, il motivo per l'errore e così via. Puoi usare questi dettagli per risolvere altri problemi.

  • La VM non si avvia e non riesci a connetterti tramite SSH o il server Google Workspace. Se la VM è inaccessibile, il sistema operativo potrebbe essere danneggiato. Se disco di avvio non si avvia, puoi diagnosticare il problema. Se vuoi ripristinare la VM danneggiata e recuperare i dati, consulta Recupero di un una VM danneggiata o un disco di avvio completo.

  • La VM è in fase di avvio in modalità di manutenzione. All'avvio in modalità di manutenzione, la VM non accetta connessioni SSH, ma puoi connetterti alla rete e accedi come utente root.

    Per risolvere il problema:

    1. Se non hai impostato una password root per la VM, utilizza una script di avvio dei metadati da eseguire il seguente comando durante l'avvio:

      echo "root:NEW_PASSWORD" | chpasswd

      Sostituisci NEW_PASSWORD` con una password a tua scelta.

    2. Riavvia la VM.

    3. Connettiti alla console seriale della VM e accedi come utente root.

Errore imprevisto

Quando provi a connetterti a una VM Linux, potrebbe verificarsi il seguente errore:

Connection Failed
You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.

Questo problema può verificarsi per diversi motivi. Di seguito sono riportate alcune cause comuni dell'errore:

  • Il daemon OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. La sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se si tratta configurato in modo errato o non in esecuzione, non puoi connetterti alla VM tramite SSH.

    Per risolvere il problema, prova una o più delle seguenti operazioni:

    • Consulta la guida dell'utente relativa al tuo sistema operativo per assicurarti che le tue sshd_config sia configurato correttamente.

    • Assicurati di disporre delle impostazioni di proprietà e autorizzazione necessarie per seguenti:

      • Directory $HOME e $HOME/.ssh
      • File $HOME/.ssh/authorized_keys

      Proprietà

      L'ambiente guest archivia le chiavi pubbliche SSH autorizzate $HOME/.ssh/authorized_keys. Il proprietario di $HOME e $HOME/.ssh e il file $HOME/.ssh/authorized_keys deve essere identico al file che si connette alla VM.

      Autorizzazioni

      L'ambiente guest richiede le seguenti autorizzazioni Linux:

      Percorso Autorizzazioni
      /home 0755
      $HOME 0700, 0750 o 0755 *
      $HOME/.ssh 0700
      $HOME/.ssh/authorized_keys 0600

      * Per scoprire quale opzione è il valore predefinito corretto autorizzazione per la directory $HOME, consulta la documentazione ufficiale per della tua distribuzione Linux specifica.

      In alternativa, puoi creare una nuova VM basata sulla stessa immagine e verificarne la autorizzazioni predefinite per $HOME.

      Per scoprire come modificare le autorizzazioni e la proprietà, consulta chmod e chown.

    • Riavvia sshd eseguendo questo comando:

      systemctl restart sshd.service

      Verifica se ci sono errori nello stato eseguendo questo comando:

      systemctl status sshd.service

      L'output dello stato può contenere informazioni quali il codice di uscita, il motivo per l'errore e così via. Puoi usare questi dettagli per risolvere altri problemi.

  • Problema del daemon SSH sconosciuto. Per diagnosticare un problema sconosciuto del daemon SSH, controlla il Log della console seriale alla ricerca di errori.

    A seconda dell'output dei log della console seriale, prova a recuperare la VM e risolvi i problemi relativi al daemon SSH nel seguente modo:

    1. Collega il disco a un altro VM Linux.
    2. Connettiti alla VM in cui è installato il disco.
    3. Installa il disco all'interno del sistema operativo in una directory MOUNT_DIR nella VM.
    4. Visualizza i log correlati a SSH, /var/log/secure o /var/log/auth.log alla ricerca di eventuali problemi/errori. Se riscontri problemi da risolvere, prova a correggili. In alternativa, crea una richiesta di assistenza e alleghiamo i log.

    5. Smonta il disco dal sistema operativo utilizzando il comando umount:

      cd ~/
umount /mnt

    6. Scollega il disco dalla VM.

    7. Collega il disco alla VM originale.

    8. Avviare la VM.

Impossibile connettersi al backend

Potrebbero verificarsi i seguenti errori quando ti connetti alla VM dalla Console Google Cloud o 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: 'failed to connect to backend'].

Questi errori si verificano quando provi a utilizzare SSH per connetterti a una VM che non ha Un indirizzo IP pubblico e per il quale non hai configurato Identity-Aware Proxy sulla porta 22.

Per risolvere il problema Crea una regola firewall su porta 22 che consente il traffico in entrata da Identity-Aware Proxy.

La chiave host non corrisponde

Quando ti connetti alla VM potrebbe verificarsi il seguente errore:

Host key for server IP_ADDRESS does not match

Questo errore si verifica quando la chiave host nel file ~/.ssh/known_hosts non corrisponde alla chiave host della VM.

Per risolvere il problema, elimina la chiave host da ~/.ssh/known_hosts e riprova a stabilire la connessione.

Il valore dei metadati è troppo grande

Quando provi ad aggiungere una nuova chiave SSH ai metadati, può verificarsi il seguente errore:

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

I valori dei metadati hanno un valore limite massimo di 256 kB. Per mitigare questo limite, procedi in uno dei seguenti modi:

Errori di Windows

Autorizzazione negata, riprova

Quando ti connetti alla VM potrebbe verificarsi il seguente errore:

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

Questo errore indica che l'utente che sta tentando di connettersi alla VM non esiste nella VM. Di seguito sono riportate alcune delle cause più comuni di questo errore:

  • La tua versione di gcloud CLI non è aggiornata

    Se gcloud CLI non è aggiornato, è possibile che tu stia tentando di connetterti utilizzando un nome utente non configurato. Per risolvere il problema, aggiorna l'interfaccia a riga di comando gcloud.

  • Hai provato a connetterti a una VM Windows per cui non è abilitato SSH.

    Per risolvere questo errore, imposta la chiave enable-windows-ssh su TRUE nel progetto o metadati dell'istanza. Per ulteriori informazioni sull'impostazione dei metadati, consulta Imposta metadati personalizzati.

Autorizzazione negata (publickey,keyboard-interactive)

Potrebbe verificarsi il seguente errore quando ti connetti a una VM che non ha SSH attivato:

Permission denied (publickey,keyboard-interactive).

Per risolvere questo errore, imposta la chiave enable-windows-ssh su TRUE nel progetto o metadati dell'istanza. Per ulteriori informazioni sull'impostazione dei metadati, consulta Imposta metadati personalizzati.

Impossibile accedere tramite SSH all'istanza

Potrebbe verificarsi il seguente errore quando ti connetti alla VM dalla 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.

Questo errore può verificarsi per diversi motivi. Di seguito sono riportati alcuni dei cause comuni degli errori:

  • Hai provato a connetterti a una VM Windows su cui non è installato SSH.

    Per risolvere il problema, segui le istruzioni per Abilita SSH per Windows su una VM in esecuzione.

  • Il server OpenSSH (sshd) non è in esecuzione o non è configurato correttamente. La sshd fornisce accesso remoto sicuro al sistema tramite il protocollo SSH. Se si tratta configurato in modo errato o non in esecuzione, non puoi connetterti alla VM tramite SSH.

    Per risolvere il problema, consulta Configurazione di OpenSSH Server per Windows Server e Windows per assicurarti che sshd sia configurato correttamente.

Timeout della connessione

Le connessioni SSH scadute potrebbero essere causate da una delle seguenti cause:

  • L'avvio della VM non è terminato. Attendi un po' di tempo per l'avvio della VM.

    Per risolvere il problema, attendi il termine dell'avvio della VM e prova a connettiti di nuovo.

  • Il pacchetto SSH non è installato. Le VM Windows richiedono l'installazione google-compute-engine-ssh prima di poterti connettere tramite SSH.

    Per risolvere questo problema, installa il pacchetto SSH.

Diagnosi delle connessioni SSH non riuscite

Le seguenti sezioni descrivono la procedura da seguire per diagnosticare la causa del connessioni SSH non riuscite e i passaggi che puoi seguire per correggerle.

Prima di diagnosticare le connessioni SSH non riuscite, completa i seguenti passaggi:

Metodi di diagnosi per VM Linux e Windows

Testa la connettività

Potresti non essere in grado di stabilire una connessione a un'istanza VM tramite SSH a causa di problemi di connettività collegati a firewall, alla connessione di rete o all'account utente. Segui i passaggi in questa sezione per identificare eventuali problemi di connettività.

Controlla le regole del firewall

Compute Engine esegue il provisioning di ogni progetto con un set di firewall predefinito che consentono il traffico SSH. Se non riesci ad accedere all'istanza, utilizza lo strumento a riga di comando gcloud compute controlla l'elenco dei firewall e verifica che sia presente la regola default-allow-ssh.

Sulla workstation locale, esegui questo comando:

gcloud compute firewall-rules list

Se manca la regola firewall, aggiungila di nuovo:

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

Per visualizzare tutti i dati associati alla regola firewall default-allow-ssh nel tuo utilizza Comando gcloud compute firewall-rules describe:

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

Per ulteriori informazioni sulle regole firewall, consulta Regole firewall in Google Cloud.

Test della connessione di rete

Per determinare se la connessione di rete funziona, testa l'handshake TCP:

  1. Ottieni il natIP esterno per la tua VM:

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

    Sostituisci VM_NAME con il nome della VM che non puoi connettersi.

  2. Testa la connessione di rete alla VM dalla workstation:

    Linux, Windows 2019/2022 e macOS 

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

    Sostituisci quanto segue:

    • EXTERNAL_IP: l'indirizzo IP esterno che utilizzi ottenuto nel passaggio precedente
    • PORT_NUMBER: il numero di porta

    Se l'handshake TCP ha esito positivo, l'output è simile al seguente:

    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 riga Connected to indica un handshake TCP riuscito.

    Windows 2012 e 2016 

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

    Sostituisci quanto segue:

    • EXTERNAL_IP: l'IP esterno che hai ottenuto in il passaggio precedente
    • PORT_NUMBER: il numero di porta

    Se l'handshake TCP ha esito positivo, l'output è simile al seguente:

    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 riga Connected: True indica un handshake TCP riuscito.

Se l'handshake TCP viene completato correttamente, viene applicata una regola firewall software non blocca la connessione, il sistema operativo sta inoltrando correttamente i pacchetti e server in ascolto sulla porta di destinazione. Se l'handshake TCP viene completato correttamente ma la VM non accetta connessioni SSH, il problema potrebbe con il fatto che il daemon sshd non è configurato correttamente o non funziona correttamente. Rivedi la guida dell'utente relativa al tuo sistema operativo per assicurarti che sshd_config sia configurato correttamente.

Eseguire test di connettività per l'analisi della configurazione del percorso di rete VPC tra due VM e verificare se la configurazione programmata deve consentire vedi Verificare la presenza di regole firewall configurate in modo errato in Google Cloud.

Connettiti come un altro utente

Il problema che ti impedisce di accedere potrebbe essere limitato al tuo utente . Ad esempio, le autorizzazioni per il file ~/.ssh/authorized_keys sull'istanza potrebbero non essere impostati correttamente per l'utente.

Prova ad accedere come un altro utente con gcloud CLI specificando ANOTHER_USERNAME con la richiesta SSH. gcloud CLI aggiorna i metadati del progetto per aggiungere nuovo utente e consentire l'accesso SSH.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Sostituisci quanto segue:

  • ANOTHER_USERNAME è un nome utente diverso dal tuo nome utente
  • VM_NAME è il nome della VM a cui vuoi connetterti

Debug dei problemi utilizzando la console seriale

Ti consigliamo di esaminare i log della console seriale per errori di connessione. Puoi accedere alla console seriale come utente root dal tuo workstation locale tramite un browser. Questo approccio è utile quando accedi con SSH o se l'istanza non ha una connessione alla rete. Il numero di serie resta accessibile in entrambe le situazioni.

Per accedere alla console seriale della VM e risolvere i problemi della VM, segui questi passaggi:

  1. Abilita l'accesso interattivo alla console seriale della VM.

  2. Per le VM Linux, modifica la password root e aggiungi il seguente script di avvio alla VM: 

    echo root:PASSWORD | chpasswd

    Sostituisci PASSWORD con una password di tua scelta.

  3. Utilizza la console seriale per connetterti alla VM.

  4. Per le VM Linux, dopo aver completato il debug di tutti gli errori, disabilita l'accesso all'account principale: 

    sudo passwd -l root

Metodi di diagnosi per VM Linux

Esamina l'istanza VM senza arrestarla

Potresti avere un'istanza a cui non puoi connetterti che continua gestire correttamente il traffico di produzione. In questo caso, potresti voler controllare sul disco senza interrompere l'istanza.

Per ispezionare il disco e risolvere i problemi:

  1. Esegui il backup del disco di avvio creando uno snapshot del disco.
  2. Crea un disco permanente standard a partire da questo snapshot.
  3. Crea un'istanza temporanea.
  4. Collega e monta il disco permanente standard sulla nuova istanza temporanea.

Questa procedura crea una rete isolata che consente solo e le connessioni SSH. Questa configurazione impedisce eventuali conseguenze indesiderate un'istanza clonata che interferisce con i servizi di produzione.

  1. Crea una nuova rete VPC per ospitare la tua istanza clonata:

    gcloud compute networks create debug-network

    Sostituisci NETWORK_NAME con il nome che vuoi chiamare nella nuova rete.

  2. Aggiungi una regola firewall per consentire le connessioni SSH alla rete:

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

  3. Crea uno snapshot del disco di avvio.

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

    Sostituisci BOOT_DISK_NAME con il nome dell'avvio disco.

  4. Crea un nuovo disco con lo snapshot che hai appena creato:

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

  5. Crea una nuova istanza di debug senza un indirizzo IP esterno:

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

  6. Collega il disco di debug all'istanza:

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

  7. Segui le istruzioni per Connettiti a una VM utilizzando un bastion host.

  8. Dopo aver eseguito l'accesso all'istanza del debugger, risolvi i problemi relativi all'istanza. Ad esempio, puoi esaminare i log dell'istanza:

    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

    Sostituisci VM_NAME con il nome della VM che non puoi connettersi.

Usa uno script di avvio

Se nessuna delle soluzioni precedenti è stata utile, puoi creare uno script di avvio per raccogliere le informazioni immediatamente dopo l'avvio dell'istanza. Segui le istruzioni per l'esecuzione di uno script di avvio.

In seguito, dovrai anche reimpostare l'istanza prima che i metadati prendano un effetto utilizzando gcloud compute instances reset.

In alternativa, puoi anche ricreare l'istanza eseguendo un test di diagnostica script di avvio:

  1. Esegui gcloud compute instances delete con il flag --keep-disks.

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

    Sostituisci VM_NAME con il nome della VM che non puoi connettersi.

  2. Aggiungi una nuova istanza con lo stesso disco e specifica lo script di avvio.

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

    Sostituisci quanto segue:

    • NEW_VM_NAME è il nome della nuova VM che stai creazione in corso
    • BOOT_DISK_NAME è il nome del disco di avvio da alla VM a cui non riesci a connetterti
    • URL è l'URL di Cloud Storage alla in uno script gs://BUCKET/FILE o https://storage.googleapis.com/BUCKET/FILE formato.

Utilizza il tuo disco su una nuova istanza

Se hai ancora bisogno di recuperare i dati dal disco di avvio permanente, puoi scollega il disco di avvio e collegalo come disco secondario su una nuova istanza.

  1. Elimina la VM a cui non riesci a connetterti e conserva il relativo disco di avvio:

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

    Sostituisci VM_NAME con il nome della VM che non puoi connettersi.

  2. Crea una nuova VM con il disco di avvio della vecchia VM. Specifica il nome del disco di avvio della VM appena eliminata.

  3. Connettiti alla nuova VM tramite SSH:

    gcloud compute ssh NEW_VM_NAME

    Sostituisci NEW_VM_NAME con il nome della nuova VM.

Controlla se il disco di avvio della VM è pieno o meno

La VM potrebbe non essere più accessibile se il disco di avvio è pieno. Questo scenario può essere difficile da risolvere poiché non è sempre evidente quando la connettività della VM è dovuto a un disco di avvio pieno. Per ulteriori informazioni su questo scenario, consulta Risoluzione dei problemi relativi a una VM inaccessibile a causa di un disco di avvio pieno.

Metodi di diagnosi per le VM Windows

Reimposta metadati SSH

Se non riesci a connetterti a una VM Windows tramite SSH, prova a annullare l'impostazione enable-windows-ssh e la riattivazione di SSH per Windows.

  1. Imposta la chiave dei metadati enable-windows-ssh su FALSE. Per informazioni su come impostare i metadati, consulta Imposta metadati personalizzati.

    Attendi qualche secondo affinché la modifica venga applicata.

  2. Riattivare SSH per Windows

  3. Riconnettiti alla VM.

Connettiti alla VM utilizzando RDP

Se non riesci a diagnosticare e risolvere la causa delle connessioni SSH non riuscite al tuo VM Windows, connettiti tramite RDP.

Dopo aver stabilito una connessione alla VM, esamina Log OpenSSH.

Debug dei problemi relativi a SSH con gcpdiag

gcpdiag è uno strumento open source che consente di identificare e risolvere i problemi relativi a Google Cloud in modo programmatico a gestire i progetti. gcpdiag non è un prodotto Google Cloud ufficialmente supportato. Per ulteriori informazioni informazioni, consulta progetto gcpdiag su GitHub.

Questo runbook di gcpdiag indaga sulle potenziali cause di problemi di connessione SSH su le VM Windows e Linux in Google Cloud esaminando le seguenti aree:
  • Integrità della VM:controlla se la VM è in esecuzione e ha una quantità sufficiente di spazio di risorse (CPU, memoria, spazio di archiviazione su disco).
  • Autorizzazioni: assicura di disporre delle autorizzazioni IAM corrette per configurare le chiavi SSH.
  • Impostazioni VM: verifica che le chiavi SSH e gli altri metadati siano configurato correttamente.
  • Regole di rete: esamina le regole firewall per confermare l'SSH. il traffico è consentito.
  • Sistema operativo guest: cerca eventuali problemi interni del sistema operativo che potrebbero bloccare SSH.

Cloud Shell

  1. Copia ed esegui questo comando in Cloud Shell: 
    gcpdiag runbook gce/ssh --project=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE \
    --parameter principal=PRINCIPAL \
    --parameter tunnel_through_iap=IAP_ENABLED \
    --parameter check_os_login=OS_LOGIN_ENABLED

Console Google Cloud

  1. Copia il seguente comando: 
    2. gcpdiag runbook gce/ssh --project=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE \
    --parameter principal=PRINCIPAL \
    --parameter tunnel_through_iap=IAP_ENABLED \
    --parameter check_os_login=OS_LOGIN_ENABLED
  2. Apri la console Google Cloud e attiva Cloud Shell:
    3. Apri la console Cloud
  3. Incolla il comando copiato.
  4. Esegui il comando gcpdiag. Verrà scaricata l'immagine Docker gcpdiag e inizierà l'esecuzione i controlli pertinenti per questo comando. Segui le istruzioni su come correggere i controlli non riusciti.

Docker

Puoi esegui gcpdiag utilizzando un wrapper che avvia gcpdiag in un container Docker. Funziona su qualsiasi macchina in cui è installato Docker o Podman.

  1. Copia ed esegui il comando seguente nella workstation locale: 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Esegui il comando gcpdiag: 
    ./gcpdiag runbook gce/ssh --project=PROJECT_ID \
    --parameter name=VM_NAME \
    --parameter zone=ZONE \
    --parameter principal=PRINCIPAL \
    --parameter tunnel_through_iap=IAP_ENABLED \
    --parameter check_os_login=OS_LOGIN_ENABLED

Visualizza tutti i parametri disponibili per questo runbook.

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto contenente la risorsa.
  • VM_NAME: il nome della VM di destinazione all'interno del progetto.
  • ZONE: la zona in cui si trova la VM target.
  • PRINCIPAL: l'entità dell'account utente o di servizio avviare la connessione SSH. Per l'autenticazione basata su chiave, utilizza autenticati dallo strumento a riga di comando di Cloud Shell o che abbiano effettuato l'accesso nella console Google Cloud. Per la simulazione dell'identità degli account di servizio, deve trattarsi l'indirizzo email dell'account.
  • IAP_ENABLED: un valore booleano (true o false) che indica se per stabilire la connessione SSH viene utilizzato Identity-Aware Proxy. Predefinita: true
  • OS_LOGIN_ENABLED: un valore booleano (true o false) che indica se OS Login viene utilizzato per l'autenticazione SSH. Predefinita: true

Flag utili:

  • --project: per definire il valore PROJECT_ID.
  • --universe-domain: se applicabile, utilizzato per definire Sovereign Cloud di Trusted Partner dominio che ospita la risorsa.
  • --parameter o -p: per definire i parametri per un runbook.

Per ulteriori informazioni sui flag disponibili, consulta la sezione Utilizzo istruzioni per gcpdiag.

Passaggi successivi